of 81/81
Assessing Web Services Robustness and Security Using Malicious Data Injection Pedro Ricardo Saraiva Bento [email protected] Mestrado em Engenharia Informática Dissertação/Estágio Relatório Final Orientador: Prof. Doutor Nuno Laranjeiro Data: 02 de Setembro de 2015

Assessing Web Services Robustness and Security Using ... Web... · aprofundada sobre dois tipos de vulnerabilidades (SQL Injection e Second-Order SQL Injection ), são descritas também

  • View
    219

  • Download
    0

Embed Size (px)

Text of Assessing Web Services Robustness and Security Using ... Web... · aprofundada sobre dois tipos de...

  • Assessing Web Services

    Robustness and Security

    Using Malicious Data

    Injection

    Pedro Ricardo Saraiva Bento [email protected]

    Mestrado em Engenharia Informtica Dissertao/Estgio Relatrio Final

    Orientador:

    Prof. Doutor Nuno Laranjeiro Data: 02 de Setembro de 2015

  • Assessing Web Services Robustness and Security Using

    Malicious Data Injection

    Relatrio Final

    Autor:

    Pedro Ricardo Saraiva Bento

    Orientador:

    Prof. Doutor Nuno Laranjeiro

    Jri:

    Prof. Doutor David Fonseca Palma

    Prof. Doutor Paulo Jos Osrio Rupino da Cunha

    Setembro 02, 2015

  • iv

  • v

    Sumrio

    A tecnologia Web Services permite ligar aplicaes criadas em diferentes plataformas,

    tendo atingido grande popularidade. Nos ltimos anos, o uso desta tecnologia tem

    aumentado consideravelmente, no s como suporte a ambientes crticos de negcio,

    mas tambm em ambientes onde a robustez e segurana dos servios vital. Nestes

    ambientes, a presena de um problema de robustez ou uma vulnerabilidade de

    segurana pode traduzir-se em perdas a nvel financeiro e/ou na reputao do fornecedor

    do servio. A falta de metodologias e ferramentas adequadas para a deteo destes

    problemas um dos fatores que contribui para a situao atual, onde os servios falham

    na presena de entradas invlidas ou maliciosas.

    Nesta dissertao discutido o estado da arte em robustez e segurana em Web Services

    sendo proposta uma abordagem para deteo de falhas desta rea. Esta baseia-se na

    introduo, em tempo de execuo, de um conjunto de inputs invlidos e maliciosos

    num servio sob teste. Contrariamente abordagem clssica para deteo destes

    problemas, as interfaces das aplicaes sob teste na abordagem apresentada, so as de

    contacto com servios externos, em particular com a base de dados. Deste trabalho

    resulta tambm a criao de uma ferramenta de testes, possibilitando a classificao do

    nvel de segurana e robustez de um servio.

    Palavras-Chave: Web Services, Segurana, SQL Injection, Second-Order SQL

    Injection, Testes de Robustez.

  • vi

  • vii

    Abstract

    The Web Services technology allows us to connect applications built on different

    platforms, reaching great popularity. In the last years, the use of this technology has

    increased considerably, not only to support the critical business environments, but also

    in environments where robustness and safety of services is vital. The presence of a

    robustness problem or a security vulnerability can be translated into substantial losses in

    financial terms and/or reputation of the service provider. The lack of methodologies and

    tools for the detection of these problems is one of the factors contributing to the current

    situation where services fail in the presence of invalid or malicious inputs.

    This dissertation discusses the state of the art of robustness and security in Web

    Services and proposes an approach for detection of this type of situations. This is based

    on the introduction, at runtime, of a set of invalid and malicious inputs to a service

    under test. Unlike the classical approach for detecting these problems, the interfaces of

    the applications under test in the developed approach, are those that contact with

    external services, in particular its interface with the database. This work also involves

    the creation of a testing tool, allowing the classification of the level of robustness and

    security of a service.

    Keywords: Web Services, Security, SQL Injection, Second-Order SQL Injection,

    Robustness Testing.

  • viii

  • ix

    Agradecimentos

    Ao meu orientador, Professor Doutor Nuno Laranjeiro, por todo o apoio,

    disponibilidade, pacincia e conhecimento acadmico que me proporcionou ao longo

    deste percurso. Muito obrigado por tudo.

    Aos prezados jris, Professores Doutores David Fonseca Palma e Paulo Jos Osrio

    Rupino da Cunha que pelas suas correes e sugestes dadas na defesa intermdia

    contriburam muito para o melhoramento desta dissertao. Muito obrigado pelos

    vossos sbios conselhos.

    A todos os professores que fizeram parte da minha vida acadmica e que com os seus

    conhecimentos fizeram de mim a pessoa que sou hoje.

    Faculdade de Cincias e Tecnologia da Universidade de Coimbra em especial ao

    Departamento de Engenharia Informtica que me acolheu e me proporcionou a minha

    formao.

    cidade de Coimbra, ao seu esprito acadmico nico e a todos os meus amigos que

    fizeram parte integrante das minhas vivncias. Em especial ao Diogo, Rafael e aos meus

    colegas de casa por me terem acompanhado durante todo este meu percurso, desde o

    primeiro dia. Obrigado pela presena constante. Jamais vos esquecerei.

    A toda a minha famlia, avs, tios, padrinhos e primos em especial ao meu primo Nuno

    pelo apoio e presena. Foram o suporte desta caminhada.

    Vanessa que com muito amor, apoio e companheirismo foi um fator facilitador para o

    meu bem-estar e fora para continuar. Muito obrigado.

    Aos meus pais amados, aos quais devo tudo o que sou hoje, um imenso e eterno

    agradecimento por todo o apoio incondicional dado durante toda a minha vida, por me

    terem dado a possibilidade de concretizar os meus sonhos e por nunca me ter faltado

    nada. Tenho um imenso orgulho em ser vosso filho e uma dvida eterna pela formao

    humana e acadmica que me proporcionaram. Um especial obrigado.

  • x

  • xi

    ndice

    Captulo 1 - Introduo ..................................................................................................... 1

    1.1 mbito e Abordagem ........................................................................................... 1

    1.2 Organizao ......................................................................................................... 2

    Captulo 2 - Estado da Arte .............................................................................................. 3

    2.1 - Web Services ........................................................................................................ 3

    2.2 Mtodos de Testes ............................................................................................... 5

    1) Black Box Tests .................................................................................................. 5

    2) White Box Tests .................................................................................................. 6

    3) Gray Box Tests ................................................................................................... 7

    2.3 Testes de Robustez ............................................................................................... 8

    2.4 Testes de Segurana ........................................................................................... 11

    2.4.1 SQL Injection .............................................................................................. 11

    2.4.2 Second-Order SQL Injection ....................................................................... 14

    2.4.3 Preveno e Deteo de SQL Injection ....................................................... 16

    Captulo 3 Metodologia e Abordagem ........................................................................ 19

    3.1 - Tcnicas para Injeo de Valores Invlidos ou Maliciosos ................................ 19

    3.2 Abordagem para Avaliao de Robustez e Segurana ...................................... 21

    1) Preparao dos Testes ..................................................................................... 22

    2) Recolha de Informao .................................................................................... 23

    3) Execuo dos Testes ........................................................................................ 23

    4) Caraterizao do Servio ................................................................................ 31

    Captulo 4 Avaliao Experimental ............................................................................. 32

    4.1 Resultados do TPC-App Web Service ............................................................... 33

    Captulo 5 - Planeamento ............................................................................................... 47

    5.1 Planeamento Primeiro Semestre ........................................................................ 47

    5.2 Planeamento Segundo Semestre ........................................................................ 48

    Captulo 6 - Concluso ................................................................................................... 51

    6.1 Obstculos Encontrados ..................................................................................... 52

    6.2 Trabalho Futuro ................................................................................................. 53

    Referncias ..................................................................................................................... 55

    Anexo A .......................................................................................................................... 60

  • xii

  • xiii

    Lista de Figuras

    2.1 Funcionamento tpico de um Web Service.....4

    2.2 Funcionamento entre um Web Service e uma Base de Dados...........4

    2.3 Abordagem Black Box Tests..............5

    2.4 Abordagem White Box Tests..................6

    2.5 Abordagem Gray Box Tests...7

    2.6 Exemplo de SQL Injection.......12

    2.7 Exemplo de Second-Order SQL Injection........15

    3.1 Funcionamento da tcnica para injeo de valores invlidos e maliciosos .....20

    3.2 Fase de testes da ferramenta.........21

    3.3 Funcionamento de um sistema sujeito ferramenta de testes......24

    4.1 Problemas de Robustez no TPC-App...34

    5.1 Fases de construo da ferramenta...........47

    5.2 Plano de trabalho efetivo do primeiro semestre...........48

    5.3 Plano de trabalho do segundo semestre ...............49

  • xiv

  • xv

    Lista de Tabelas

    3.1 Tabela de Testes de Robustez.....25

    3.2 Tabela de Testes de Segurana...29

    4.1 Tabela de problemas de Robustez I do TPC-App..........36

    4.2 Tabela de problemas de Robustez II do TPC-App.39

    4.3 Tabela de falhas de Segurana do TPC-App..43

  • xvi

  • xvii

    Lista de Acrnimos

    CORBA Common Object Request Broker Architecture

    DAST Dynamic Application Security Testing

    HTTP Hyper-Text Transfer Protocol

    JDBC Java Database Connectivity

    MAFALDA Microkernel Assessment by Fault Injection Analysis and Design

    Aid

    POA Programao Orientada a Aspetos

    SGBD Sistemas de Gesto de Bases de Dados

    SOAP Simple Object Access Protocol

    SQL Structured Query Language

    WSDL Web Service Definition Language

    XML eXtensible Markup Language

  • xvii

  • 1

    Captulo 1 - Introduo

    A dissertao aqui apresentada surge da necessidade crescente da procura de mtodos e

    abordagens que permitam mitigar os riscos de ataques por Structured Query Language

    (SQL) Injection a Web Services, podendo estes ter causas devastadoras aquando do

    sucesso do referido ataque. A mitigao destes riscos pode ser alcanada atravs de um

    maior investimento em scanners e abordagens de segurana e robustez, que permitam

    expor vulnerabilidades existentes nas aplicaes Web, podendo ser consequentemente

    corrigidas para impedir que se tornem alvos de hackers em busca de informao valiosa.

    De modo a evitar este tipo de situaes, discute-se neste relatrio o estado da arte

    referente robustez e segurana nos Web Services e uma abordagem para deteo deste

    tipo de falhas. As vulnerabilidades de segurana a que esta abordagem d resposta so

    as sensveis aos ataques por SQL Injection, no detetando por isso outro tipo de falhas.

    Esta dissertao foi produzida no mbito da disciplina dissertao/estgio em

    Comunicaes, Servios e Infraestruturas do Mestrado em Engenharia Informtica, pelo

    aluno Pedro Ricardo Saraiva Bento e orientada pelo Prof. Doutor Carlos Nuno Bizarro e

    Silva Laranjeiro, nas instalaes do Departamento de Engenharia Informtica, da

    Faculdade de Cincias e Tecnologia da Universidade de Coimbra.

    1.1- mbito e Abordagem

    Em ambientes baseados em Web Services, a presena de um problema de robustez ou

    vulnerabilidade de segurana pode causar danos irrecuperveis, tais como a eliminao

    de toda a informao existente numa base de dados, fuga de informao confidencial e

    negao de servio. Atualmente, as abordagens e ferramentas para deteo de

    problemas de robustez focam-se nas interfaces pblicas dos servios, esquecendo que a

    natureza dos Web Services faz com que eles estejam muitas vezes ligados a outros

    servios, incluindo Sistemas de Gesto de Bases de Dados (SGBD). Esta dissertao

    foca-se, precisamente, neste problema, ou seja, na interao de um servio com um

    SGBD, e tenta definir uma abordagem que permita compreender o comportamento de

    um servio na presena de dados invlidos ou maliciosos. Apesar do mbito desta

    dissertao se centrar principalmente em Web Services que recorrem a sistemas que

    comunicam com bases de dados, a tcnica usada pode ainda ser aplicada em qualquer

    outro ambiente, diferindo no comportamento observvel. Este foco est relacionado

    com o facto de que os ataques por SQL Injection serem os mais frequentes neste tipo de

    ambientes [1].

    A abordagem proposta neste documento atua entre o sistema sob teste e os sistemas

    externos que usa, em particular o SGBD e tem como objetivo revelar problemas de

    robustez e segurana existentes na aplicao. A particularidade do mtodo que no

    requer alteraes no sistema (base de dados, cliente ou aplicao), sendo apenas

    necessrio substituir o componente que permite interagir como SGBD, por exemplo, o

    driver Java Database Connectivity (JDBC). Um dos objetivos que a ferramenta criada

    e que implementa a abordagem seja o menos intrusiva possvel.

    Os objetivos desta dissertao so os seguintes:

    Definio de uma abordagem para deteo de problemas de robustez e segurana: A abordagem envolve a injeo de dados invlidos e maliciosos nos

  • 2

    resultados provenientes dos acessos base de dados. Esta deve ser prtica e o

    menos intrusiva possvel;

    Criao de uma ferramenta que implemente a abordagem definida: este objetivo baseou-se na criao de uma ferramenta de testes que permitiu testar o

    nvel de robustez e segurana do servio. Assim conseguiu-se detetar as falhas

    existentes no sistema alvo, de modo a possibilitar a sua correo evitando deste

    modo, que ataques maliciosos aplicao sejam bem sucedidos;

    Aplicao da abordagem a um ambiente realista: para alm da construo da ferramenta, um dos principais objetivos consistiu em usar a ferramenta em

    servios reais para executar todos os testes de robustez e segurana que foram

    definidos durante este ano letivo. Deste modo foi possvel verificar se estes

    servios continham vulnerabilidades. Seguiu-se a anlise e discusso dos

    resultados obtidos.

    1.2 Organizao

    O estado da arte apresentado no Captulo 2, incluindo: uma breve introduo aos Web

    Services e sua interao com bases de dados; uma breve explicao sobre os mtodos

    de testes de robustez existentes; e por fim, para alm de uma explicao mais

    aprofundada sobre dois tipos de vulnerabilidades (SQL Injection e Second-Order SQL

    Injection), so descritas tambm algumas abordagens cuja finalidade a deteo destas

    falhas.

    No Captulo 3 apresentam-se algumas tcnicas para injeo de valores invlidos ou

    maliciosos, incluindo uma explicao da abordagem definida e dos testes que foram

    executados e o mtodo utilizado para a avaliao dos testes de robustez e de segurana.

    O plano do trabalho produzido ao longo do ano letivo demonstrado no Captulo 4.

    Finalmente, o Captulo 5 conclui esta dissertao.

  • 3

    Captulo 2 - Estado da Arte

    No presente captulo so discutidos os conceitos bsicos sobre Web Services e o seu

    modo de interao com bases de dados (Seco 2.1). So ainda descritos, na Seco 2.2,

    os black box tests, white box tests e gray box tests, necessrios para a compreenso do

    contedo existente neste relatrio. Segue-se, na Seco 2.3, uma introduo aos testes

    de robustez, que estiveram presentes na aplicao elaborada durante o presente ano

    letivo, de modo a comprovar a robustez de aplicaes sujeitas a esta ferramenta. Por

    fim, na Seco 2.4 so descritos dois tipos de testes de segurana (SQL Injection e

    Second-Order SQL Injection), assim como mtodos usados neste tipo de testes, sendo o

    ltimo o principal foco desta dissertao.

    2.1 - Web Services

    A tecnologia de Web Services muitas vezes uma soluo utilizada em Integrao de

    Sistemas que permite a comunicao entre diferentes aplicaes, quer sejam aplicaes

    novas ou antigas [2]. Com esta tcnica (Web Services) existe a possibilidade das

    aplicaes enviarem e receberem dados entre elas, apesar de conterem linguagens

    diferentes. Este processo feito atravs da transformao dos dados em formato

    eXtensible Markup Language (XML), que permite estabelecer ligaes entre aplicaes

    completamente diferentes. Depois de sofrerem esta transformao, os dados so

    encapsulados pelo protocolo Simple Object Acess Protocol (SOAP) e tipicamente

    enviados atravs do protocolo Hyper Text Transfer Protocol (HTTP) [3].Este modo de

    funcionamento permite a comunicao entre aplicaes heterogneas [4]. Web Services

    tm neste momento uma grande adeso, tendo j atingido uma grande variedade de

    setores, desde lojas online a corporaes de media.

    Tal como foi referido, o protocolo SOAP [5] usado para realizar a troca de mensagens

    XML [6] entre as duas extremidades, consumidor (Service Consumer) e fornecedor

    (Service Provider), tipicamente usando o protocolo HTTP ou Hyper Text Transfer

    Protocol Secure (HTTPS). A cada ligao o consumidor (cliente) envia um pedido

    SOAP para o fornecedor (servidor). Depois de processar toda a informao enviada na

    mensagem de pedido, o servidor envia uma resposta mais uma vez no formato SOAP

    com o resultado obtido. Todo este funcionamento pode ser observado na Figura 2.1,

    onde se representa um ambiente tpico baseado em Web Services.

  • 4

    Figura 2.1 Funcionamento tpico de um Web Service (adaptado de [7]).

    Os Web Services fazem uso de um documento XML, utilizado para descrever o servio,

    cujo nome Web Service Definition Language (WSDL) [3]. Este documento para alm

    de oferecer uma descrio do Web Service, possibilita tambm a sua localizao e

    fornece informao sobre os mtodos disponveis pelo servio. Como possvel

    observar na Figura 2.1 existe tambm um broker que fornece as informaes sobre os

    Web Services disponveis ao Service Consumer, ou seja, o broker responsvel por

    enviar ao Service Consumer todas as informaes sobre outros Web Services existentes,

    como por exemplo o tipo de operaes que contm.

    A maioria dos Web Services recorrem a bases de dados de modo a poderem guardar a

    informao necessria para o funcionamento do servio. Estes servios tm o nome de

    Database Web Services [8], criados devido necessidade crescente de aceder a dados

    atravs de interfaces de Web Services em ambientes heterogneos. Na Figura 2.2

    apresentado um exemplo de um destes casos.

    Figura 2.2 Funcionamento entre um Web Service e uma Base de Dados.

    A ligao entre a base de dados e o Web Service, como mostra a Figura 2.2, feita

    atravs de um componente middleware, por exemplo, na linguagem Java, driver JDBC

    [9] que contm a definio de mtodos que permitem estabelecer esta ligao. Este

    componente permite que a aplicao envie instrues SQL para a base de dados e

    retorne os seus respetivos resultados. Estas instrues SQL recebidas pelo componente,

    so processadas e reencaminhadas para a base de dados. Esta ao receber o pedido vai

  • 5

    process-lo retornando um resultado correspondente pesquisa realizada. Este ResultSet

    vai ser guardado e traduzido pelo componente middleware atrs referido, que ser

    posteriormente retornado para a aplicao, com todo o contedo encontrado com a

    pesquisa efetuada.

    2.2 Mtodos de Testes

    Como acima referido existem trs grupos de testes de software, sendo estes, Black Box,

    White Box e Gray Box Tests [10].

    1) Black Box Tests

    Na Figura 2.3 so ilustrados os testes Black box.

    Figura 2.3 Abordagem Black Box Tests. Adaptado de [11].

    Neste tipo de testes, o analista no tem acesso ao cdigo fonte e desta forma desconhece

    a estrutura interna da aplicao, ou seja, os testes a serem realizados esto relacionados

    com os requisitos da aplicao e com as aes que esta elaborar. Este tipo de testes

    envolve a injeo de parmetros vlidos e invlidos, e objetiva a observao do

    comportamento da aplicao quando submetida a diferentes inputs. Estes testes so

    projetados com o intuito de descobrir erros na aplicao e demonstrar que as funes

    existentes no software em questo, esto operacionais, isto que as entradas so

    devidamente aceites e as suas sadas corretamente produzidas, e que a integridade das

    informaes externas mantida. Um dos objetivos destes testes contrariar as aes

    requeridas pelo servio, por exemplo, quando a aplicao pede para inserirmos o

    nmero de identificao fiscal e ns introduzimos um nmero negativo ou quando a

    aplicao pede a introduo de uma data de nascimento, qual respondemos com uma

    data futura, entre outros [12]. Este tipo de testes possui vantagens e desvantagens.

    Algumas das vantagens so:

    Eficiente quando usado em sistemas de grandes dimenses [10];

    Equilbrio e imparcialidade dos testes, caso o analista e o programador sejam diferentes [12];

    No exigido ao analista o conhecimento da implementao da aplicao, nem da lngua de programao usada [13].

  • 6

    No entanto, este tipo de testes possui algumas limitaes/desvantagens, tais como:

    Falta de cobertura que os testes podem ter na aplicao, sendo esta um fator limitante, visto no se possuir informao sobre a aplicao [10];

    Falta de informao sobre a estrutura do sistema no permite a execuo de testes em funes especficas [13];

    Possibilidade de repetio de testes, j efetuados anteriormente pelo programador, caso o analista e o programador sejam diferentes.

    Este foi o tipo de testes usados no trabalho desenvolvido, visto que a tcnica

    implementada na ferramenta criada permite que os testes sejam aplicados sem se

    conhecer a aplicao alvo e o analista da aplicao no ser o mesmo que o programador.

    2) White Box Tests

    Relativamente aos testes White Box, a diferena em relao aos testes Black Box

    referidos anteriormente, que o analista conhece o cdigo fonte, como podemos

    observar na Figura 2.4, tem acesso a este desde o incio, logo conhece a estrutura interna

    da aplicao e desse modo pode escolher os alvos dos testes. Consequentemente, existe

    um maior controlo e uma maior facilidade em entender o comportamento da aplicao e

    das suas funes [14], o que permite uma maior facilidade na deteo de erros lgicos

    no programa. Estes testes incluem a anlise de fluxos de dados, controlo e informao,

    prticas de cdigo, tratamento de excees e erros no sistema, cujo objetivo observar o

    comportamento da aplicao ao estar sujeita a aes que afetam o normal

    funcionamento da mesma.

    Figura 2.4 Abordagem White Box Tests. Adaptado de [11].

    Assim como os testes Black Box, os testes White Box possuem vantagens e

    desvantagens. Algumas das vantagens so:

    Possibilidade de analisar o cdigo linha a linha, de modo a excluir toda e qualquer hiptese de existncia de erros e/ou vulnerabilidades [13];

    Possibilidade de eliminar cdigo desnecessrio (e.g., caminhos desnecessrios entre operaes, cdigo que no utilizado) [10];

    Possibilidade de testar a aplicao enquanto esta ainda se encontra em desenvolvimento.

  • 7

    Algumas das desvantagens so:

    Dispendioso tendo em conta que requer a presena de um analista com elevada experincia e conhecimento a nvel de programao para a criao dos testes

    [12];

    A anlise exaustiva do cdigo, linha a linha, depende do tempo e oramento do projeto, o que pode fazer com que existam caminhos da aplicao que no so

    testados, resultando na possibilidade de existncia de erros que no so

    detetados [13];

    O tempo necessrio que este tipo de testes requer muito elevado [10].

    O tipo de testes mencionado tambm foi usado algumas vezes durante o

    desenvolvimento da ferramenta, de modo a serem descobertos erros existentes que

    comprometam o bom funcionamento da mesma.

    Um dos mtodos usados em White Box Testing, recorre anlise de cdigo esttico

    especialmente em revises de cdigo. Pesquisas feitos ao longo dos anos comprovaram

    que a anlise do cdigo uma das melhores maneiras para detetar e eliminar bugs

    existentes [15]. Tendo-se observado que esta deteo nem sempre possvel atravs de

    profissionais experientes, optou-se pela implementao de analisadores estticos, ou

    seja: programas que percorrem o cdigo existente numa aplicao, procura de

    excees particulares e erros que dificilmente so detetados, enquanto o cdigo fonte se

    encontra esttico (sem estar a correr), atravs de tcnicas como Data Flow Analysis e

    Taint Analysis [16]. Estas ferramentas servem de suporte aos programadores para ajudar

    a combater a existncia de bugs nas aplicaes em desenvolvimento.

    3) Gray Box Tests

    Alm dos testes apresentados acima, existem ainda os Gray Box Tests (ver Figura 2.5).

    Figura 2.5 Abordagem Gray Box Tests.

    Estes testes so uma combinao de White Box Tests e Black Box Tests, ou seja, no so

    considerados testes Black Box porque o analista tem acesso a algumas operaes

    internas do sistema, mas tambm no so considerados testes White Box j que estes

    tm acesso limitado ao cdigo fonte da aplicao. Os Gray Box Tests baseiam-se num

    conhecimento limitado sobre a aplicao. Estes so usados para obter os benefcios de

  • 8

    Black Box Testing e White Box Testing, para tratar situaes de testes mais complexos

    de forma mais eficiente [17].

    Um mtodo Gray Box Testing, para fazer testes de desempenho em runtime, de fcil

    implementao, atravs da utilizao de software e hardware Commercial Off the Shelf,

    apresentado por Coulter [18]. O autor usa um mtodo modificado de Gray Box

    Testing, devido ao facto de o mtodo original no suportar testes em tempo de

    execuo, ou testes ao nvel do sistema. O foco deste artigo incluir a verificao e

    validao do desempenho em tempo real na metodologia deste tipo de testes, sem alterar

    as intenes do mtodo original dos testes Gray Box.

    A ferramenta desenvolvida recorreu apenas a testes Black Box, para realizar os testes,

    visto que no necessita de qualquer conhecimento inicial sobre o cdigo da aplicao

    alvo, para poder aplicar os testes definidos.

    2.3 Testes de Robustez

    O objetivo destes testes observar o comportamento de uma aplicao na presena de

    inputs invlidos/inesperados. Espera-se com estes, expor a aplicao alvo a problemas

    de robustez, atravs da ocorrncia de excees que exponham erros de programao ou

    de design. As aplicaes so avaliadas consoante o nmero e tipo de erros detetados

    aps a fase de testes estar concluda. Existem vrios estudos que recorrem a este tipo de

    testes para avaliar a robustez de sistemas operativos, sendo [19] e [20] os que

    apresentam as ferramentas de teste de robustez mais conhecidas para os testes em

    questo, denominadas Ballista e Microkernel Assessment by Fault Injection Analysis

    and Design Aid (MAFALDA) respetivamente.

    Ballista uma ferramenta que especializada em realizar testes de robustez (Black Box)

    em sistemas operativos [20], usando uma combinao de parmetros vlidos e invlidos

    usados nas chamadas de sistema, para bloquear o sistema operativo em questo. Estes

    parmetros so retirados aleatoriamente de uma base de dados que contm todos os

    testes predefinidos a serem efetuados pela ferramenta. A robustez da aplicao

    avaliada segundo a escala CRASH, que apresenta as seguintes classificaes:

    Catastrophic (o sistema operativo fica corrompido; a mquina desliga ou reinicia e o

    problema persiste), Restart (a aplicao bloqueia e precisa de ser terminada fora),

    Abort (aplicao termina de forma anormal (abortou por si)), Silent (nenhum

    erro/exceo foi assinalado, quando deveria ter sido) e Hindering (o cdigo de erro

    retornado no o correto).

    As interfaces Portable Operating System Interface for Unix foram os primeiros alvos

    desta ferramenta de testes de robustez, tendo sido mais tarde adaptada para sistemas

    operativos Windows [21]. Neste estudo so apresentados os resultados da execuo de

    testes, que envolvem o tratamento de excees sobre vrias funes e chamadas ao

    sistema, resultantes da execuo da ferramenta de testes de robustez Ballista. Os

    sistemas operativos sujeitos a estes testes foram o Windows 95, 98, CE, NT, 2000 e

    Linux. Apesar destes testes resultarem na deteo de vrios problemas de robustez em

    todos os sistemas operativos, os mais graves foram detetados no Windows 95, 98 e CE,

    cujos sistemas operativos deixaram de funcionar por completo. Esta ferramenta tambm

    foi adaptada para vrias implementaes de Common Object Request Broker

    Architecture (CORBA) [22], assim como a sua classificao de falhas, de maneira a

    caraterizar melhor o contexto CORBA.

  • 9

    MAFALDA uma ferramenta que permite a caraterizao do comportamento de

    microkernels na presena de falhas [19]. Tal como a ferramenta Ballista, a MAFALDA

    uma ferramenta desenvolvida com o intuito de testar sistemas operativos. Esta suporta

    injeo de falhas tanto nos parmetros s chamadas de sistema como nos segmentos de

    memria. Esta corrupo feita atravs da inverso de um valor de um bit dentro de

    uma sequncia de bytes, bit-flip. Apesar desta mesma possuir estes dois mtodos de

    injeo de falhas, apenas um considerado nos testes de robustez, injeo de falhas nos

    parmetros s chamadas de sistema. A robustez da aplicao avaliada segundo a

    seguinte classificao: Erro detetado (o sistema operativo deteta o erro e reporta-o para

    a camada de aplicao), Morte do kernel (o microkernel congela, ou seja, o microkernel

    entra em loop infinito, dead lock ou espera um evento que no existe), Erro propagado

    (o erro no detetado pelos mecanismos de deteo de erros do microkernel e por isso o

    erro propaga-se para a camada de aplicao).

    Assim como a ferramenta Ballista, MAFALDA tambm sofreu uma evoluo para

    Microkernel Assessment by Fault Injection Analysis and Design Aid for Real Time

    (MAFALDA-RT) systems [23], sendo melhorada com o objetivo de ampliar a anlise de

    comportamentos de uma aplicao sujeita a falhas, de modo a incluir medidas de tempo

    de resposta. Esta ferramenta foi tambm usada num estudo [24], que tinha como

    objetivo, melhor-la, de modo a permitir a caraterizao de middleware baseado em

    CORBA. Este gnero de testes teve tanto sucesso que comearam a surgir estudos

    focados em componentes especficos de um sistema operativo [25]. Neste estudo, foi

    investigada a robustez das propriedades dos drivers dos dispositivos do Windows.

    Kernels mais recentes de sistemas operativos tm tendncia a ser cada vez mais finos,

    devido existncia dos drivers dos dispositivos. A estes so atribudas as respetivas

    tarefas existentes, sendo que grande parte dos crashes do sistema devem-se a bugs

    existentes nestes drivers dos dispositivos. O mesmo estudo conclui, baseado na robustez

    das propriedades do Windows (XP, Server 2003 e Vista), que na maioria dos casos, as

    verses dos sistemas operativos testadas, tendem a ser vulnerveis, visto que sofrem

    crashes de sistema quando so sujeitos injeo de dados maliciosos especficos, o que

    nos permite realar a importncia dos testes de robustez.

    Um dos primeiros exemplos de testes de robustez aplicados a Web Services pode ser

    encontrado no trabalho publicado por Siblini e Mansour [26]. Os autores propem o uso

    da anlise da mutao de parmetros como tcnica de testes de robustez para aplicar em

    Web Services, onde o ficheiro que descreve um Web Service (definido atravs do uso de

    WSDL), inicialmente dividido. Aqui so introduzidos operadores de mutao,

    resultando na existncia de diversos documentos modificados, que sero usados para

    testar o servio. O conjunto de mutaes que podem ser aplicadas interface do

    documento, est relacionada com as chamadas de operaes, mais precisamente,

    mensagens de entrada, mensagens de sada e respetivos tipos de dados. Os autores do

    estudo em questo, tentaram focar-se nos erros dos programadores responsveis pelo

    desenvolvimento do Web Service, erros comuns estes que ocorrem ao definir,

    implementar e usar estas interfaces. Apesar de ser uma abordagem diferente, no a

    mais indicada, visto que os parmetros de operadores de mutao, so muito limitados e

    consistem basicamente em adicionar, apagar, trocar elementos ou criar tipos complexos

    a nulo.

    Em [27] usada uma abordagem que recorre alterao do esquema XML atravs da

    utilizao de operadores de perturbao. apresentada uma forma de criar um esquema

    XML virtual, que utilizada quando no existem esquemas XML e definido um modelo

  • 10

    formal de um esquema XML. So criados operadores de perturbao baseados no

    modelo, que so usados para modificar os esquemas reais ou virtuais, com o objetivo de

    cobrir todas as reas de teste que foram definidas.

    Uma metodologia para analisar a qualidade dos servios compostos que usam tcnicas

    de injeo de falhas, apresentada em [28]. Esta baseia-se em dois aspetos principais: a

    reao dos servios compostos quando submetidos a dados maliciosos e o efeito de

    atrasos neste tipo de servios. Estes dados maliciosos incluem a substituio de dgitos

    num nmero, inverso de carateres em strings e datas e representao de datas em

    formatos diferentes. Neste estudo podia ter sido considerado tambm o uso de

    condies de limite, ou seja, explorao dos limites dos dados, por exemplo, aceder a

    uma posio de uma string que no exista, ou que exceda o seu tamanho.

    apresentada uma framework para testar a robustez de servios construda com Web

    Services - Business Process Execution Language em [29], tendo em conta que a

    composio de vrios servios, pode resultar num servio composto, com maiores

    vulnerabilidades a nvel de robustez em relao a um mais simples, devido

    complexidade existente no caso composto. Estes so tambm mais complexos no que

    toca elaborao de testes em relao aos testes em aplicaes normais, devido ao

    nmero de cenrios de teste e ao custo que estes acarretam, que aumenta com o aumento

    de servios de componente. A framework de testes apresentada, introduz um servio

    virtual, que corresponde a um servio de componente real. Esta simula situaes dentro

    do servio real, que fogem rotina do sistema, permitindo deste modo avaliar a robustez

    do servio, quando submetido a situaes excecionais.

    Rabhi em [30], apresenta um mtodo de testes de robustez para Web Services

    compostos, que tem como foco testar automaticamente a robustez das operaes dos

    servios neles existentes. Um Web Service composto, um conjunto de Web Services

    que forma um novo servio mais complexo a nvel funcional. O autor comea por

    apresentar outros mtodos existentes para testar a robustez de servios compostos

    seguindo-se a descrio da sua abordagem. Nesta so usadas especificaes simblicas

    que modelam o comportamento de um Web Service composto. A partir destas

    traduzida automaticamente uma rvore de execuo simblica que caracteriza os

    caminhos de execuo seguidos durante a execuo simblica. A partir desta so

    geradas outras subrvores por cada operao que permitem que o analista distinga os

    comportamentos das vrias operaes e configure um conjunto de casos de teste que vai

    aplicar a cada operao. De seguida so geradas subespecificaes que so completadas

    usando regras de robustez apresentadas no artigo, sendo injetados valores especficos

    nos casos de teste que vo testar o comportamento dos servios.

    Cong et al. [31], realam a importncia dos testes de robustez no ciclo de

    desenvolvimento dos drivers. A gerao e injeo de cenrios de falhas eficientes so

    um fator importante para testar a robustez dos drivers de modo a poupar tempo e

    recursos. Neste artigo, apresentada uma abordagem que permite a gerao e injeo de

    cenrios de falhas automaticamente para testar esta robustez. Nesta, comea por se

    identificar funes alvo que possam falhar quando so invocadas por drivers. Segue-se

    a configurao das falhas e gerao dos respetivos cenrios que vo permitir testar a

    robustez dos drivers. Para melhor compreenso dos resultados por parte do analisador

    usado o stacktrace, com o objetivo de analisar todo o caminho percorrido e quais os

    mtodos envolvidos. Todos os resultados obtidos so guardados numa base de dados,

    tendo sido considerados trs resultados possveis para a caracterizao do driver: pass

  • 11

    (o driver trata o cenrio de falhas com sucesso), fail (o sistema ou o driver deixam de

    funcionar resultando na ocorrncia de um crash) e null (resultado inicial antes dos testes

    serem aplicados). Esta abordagem foi aplicada em doze drivers do Linux onde se

    observou a existncia de vinte e oito bugs. Para confirmao dos mesmos, os autores

    procederam sua validao manualmente. Conclui-se com este artigo, que atravs dos

    resultados obtidos, a abordagem til e eficiente no que toca gerao de injeo de

    cenrios de falhas para testar a robustez de drivers.

    Apesar de existirem diversos scanners para tratar este tipo de problemas, as abordagens

    usadas contm algumas limitaes. A grande maioria das abordagens existentes,

    recorrem aplicao de testes a partir do cliente, onde a robustez maior, em vez de

    aplicarem os testes a partir da base de dados, onde a robustez menor, visto que o

    tratamento de dados provenientes da base de dados de baixa qualidade,

    considerando-se, de forma errada, que os dados que esto inseridos na base de dados so

    seguros e j foram tratados anteriormente, antes da sua insero [32]. No entanto,

    existem alguns mtodos que envolvem a alterao dos dados na base de dados,

    possuindo ainda assim a limitao de ser necessrio alterar o contedo da base de dados

    propositadamente, para ser possvel a aplicao dos testes, o que acaba por se tornar

    pouco prtico e de qualidade questionvel. Numa situao ideal, a aplicao deveria ser

    feita a partir da base de dados, visto que esta a parte mais suscetvel a falhas, mas sem

    haver interferncias no seu contedo.

    2.4 Testes de Segurana

    medida que o uso de Web Services aumenta, aumentam tambm os riscos associados

    sua segurana. Logo, torna-se indispensvel pensar na proteo e segurana destes

    servios, com o objetivo de evitar possveis ataques que possam comprometer dados

    sigilosos, arruinar bases de dados, entre outros j referidos anteriormente. Muitas das

    falhas de segurana resultam da fraca ou inexistente verificao ou validao dos dados

    [33].

    Na Subseco 2.4.1 so apresentados conceitos bsicos de SQL Injection, apesar de este

    mtodo no ser o foco nesta dissertao. Seguidamente ainda feita uma explicao

    detalhada, na Subseco 2.4.2, sobre Second-Order SQL Injection. A opo pela anlise

    e tratamento destes dois casos de segurana nesta dissertao deveu-se ao facto de

    serem os ataques mais frequentes em Web Services [34].

    2.4.1 SQL Injection

    Ataques por SQL Injection tm marcado presena nos servios Web existentes h mais

    de uma dcada, prevalecendo sobre toda a segurana que tem acompanhado o seu

    desenvolvimento, devendo-se em grande parte atratividade da informao que se

    encontra dentro das bases de dados. Segundo o relatrio de Veracodes 2015 State of

    Security Software [35], o valor destes dados faz com que o nmero de ocorrncias de

    ataques existentes, atinjam mais de 30% dos mais de 208.000 Web Services testados

    desde Outubro de 2013.

  • 12

    Uma das maiores preocupaes das aplicaes Web Services a fuga de informao

    confidencial, a qual pode ser alcanada, por exemplo, atravs de ataques de SQL

    Injection. Este gnero de ataques aproveita-se de falhas em sistemas que recorrem ao

    uso de bases de dados via SQL. Isto ocorre quando o atacante, atravs de injees de

    comandos, introduz instrues SQL maliciosas dentro de uma consulta (query),

    alterando a estrutura da instruo SQL original, o que permite a leitura, alterao e

    remoo de informaes e recursos importantes, acabando por corromper bases de

    dados inteiras [36]. Atravs da manipulao das entradas de dados de uma aplicao, ou

    seja, basta que o utilizador possua alguns conhecimentos de SQL, e alguma dedicao

    para descobrir nomes de tabelas e campos, para poder recorrer a este mtodo e causar

    problemas a uma aplicao que seja vulnervel. Um modo de testar a vulnerabilidade da

    aplicao, e um mtodo bastante usado para fazer SQL Injection, o uso de apstrofos

    pelo utilizador no input (ver Figura 2.6). Caso o atacante receba um erro de sintaxe por

    parte da aplicao, existe uma grande possibilidade de que esta seja vulnervel a este

    tipo de ataques. Tal acontece devido falta de tratamento adequado de excees que

    consigam prevenir este tipo de situaes, nomeadamente quando se trata de software

    desenvolvido sem conhecimentos tcnicos adequados, que por norma, no passa pelos

    mesmos testes de segurana que o software desenvolvido por pessoal devidamente

    qualificado.

    Figura 2.6 Exemplo de SQL Injection (adaptado de [37]).

    Como se pode verificar, uma coisa to simples como um formulrio de login, pode ser a

    causa de graves problemas (ver Figura 2.6).

    Considerando o seguinte exemplo:

    SELECT * FROM users WHERE username = 'myuser' AND password =

    'password';

    A instruo SQL referida anteriormente, mostra todos os registos da tabela utilizadores

    para um determinado username e password fornecidos pelo utilizador. Visto que a

  • 13

    concatenao da query com o input direto do utilizador torna esta aplicao vulnervel,

    basta que o utilizador insira or 1 = 1, para que resulte na seguinte query;

    SELECT * FROM users WHERE username = '1' OR '1' = '1' AND

    password = '1' OR '1' = '1';

    Com este comando, o utilizador ao usar 1 OR 1 = 1 vai criar uma condio que

    sempre verdadeira devido clusula OR 1 = 1 , pois 1 vai ser sempre igual a 1,

    logo se esta condio sempre verdadeira, ento significa que o processo de

    autenticao vai ser sempre aceite.

    Em [38] so explicados vrios mtodos para realizar ataques de SQL Injection e

    tambm algumas tcnicas que ajudam na preveno dos mesmos. Nesta publicao so

    referenciados ataques baseados em tautologias, Union Query e Blind Injection.

    Tautology-based attacks, so aplicados atravs da injeo de cdigo em instrues SQL,

    que usa condies que sejam sempre verdadeiras. Este foi o tipo de ataque usado como

    exemplo anteriormente. Union Query attacks, referem-se a ataques que so executados

    atravs do uso da clusula Union. O atacante adiciona uma instruo SQL com a

    clusula Union instruo original, com o objetivo de retirar informaes adicionais da

    base de dados. Um outro tipo de ataque referido neste artigo o Blind Injection, onde o

    atacante tenta adivinhar o que existe na base de dados, atravs do mtodo tentativa e

    erro, analisando as respostas enviadas pelo servidor para conseguir realizar um ataque

    com sucesso.

    Tendo j sido discutida a forma como usar SQL Injection para passar por um simples

    processo de autenticao, importa agora verificar at que ponto este tipo de ataques

    pode ser grave. A principal consequncia de um ataque de SQL Injection bem sucedido

    est relacionada com o comprometimento da confidencialidade dos dados, da

    integridade da aplicao/base de dados, da autenticao nas aplicaes e da informao

    de autorizaes (permisses). Por exemplo, se um atacante conseguir efetuar um ataque

    que lhe permita obter direitos de administrador na base de dados, isto implica que se

    torna possvel apagar toda a informao existente na base de dados. Para alm desta

    consequncia existem outras: obteno de informao confidencial e alteraes em

    bases de dados.

    Leonard e Sims [39], apresentaram a anlise de uma ferramenta que executa este tipo de

    ataques, para verificar se existem vulnerabilidades em Web Services, cujo nome HP

    WebInspect. Esta ferramenta foi criada pela SPI Dynamics, a qual foi comprada pela HP

    em 2007. WebInspect uma aplicao dinmica de testes de segurana, Dynamic

    Application Security Testing (DAST), que testa a segurana de aplicaes web

    automaticamente, atravs da execuo de ataques s mesmas. Esta usa agentes de

    avaliao que atuam em diferentes partes da aplicao, os quais enviam os resultados

    obtidos da sua anlise, para um componente de segurana que avalia estes dados. No

    fim da anlise do sistema, gerado um relatrio que contm todas as falhas de

    segurana encontradas no Web Service. Atravs deste relatrio, o cliente pode corrigir

    as falhas encontradas e depois correr a ferramenta novamente, de modo a confirmar a

    correo destas vulnerabilidades. Esta aplicao utiliza o mtodo de execuo de testes

    Black Box referido anteriormente, para fazer a anlise de segurana da aplicao em

    questo. O autor fecha este artigo com uma concluso que envolve sugestes referentes

    ao modo como podem ser combatidos estes ataques e reala a importncia de

    implementar uma ferramenta DAST desde o incio, durante o desenvolvimento de uma

    aplicao.

  • 14

    Uma nova abordagem apresentada em [40], onde os autores referem a importncia de

    ter um bom scanner que permita expor vulnerabilidades de SQL Injection numa

    aplicao. O artigo conclui que muitos dos scanners existentes so pouco eficientes e os

    resultados obtidos a partir destes so a prova disso, evidenciando o quo importante a

    segurana nos Web Services e o quo medocres so os meios existentes para a

    assegurar. Com o objetivo de contrariar esta situao, apresentada uma ferramenta que

    consegue obter resultados mais eficazes do que os scanners comerciais existentes. Esta

    inclui vrias fases no seu procedimento dos testes, desde a sua preparao sua anlise.

    Durante a fase de execuo so mencionados alguns casos de SQL Injection com os

    quais os autores trabalharam, que permitiram compreender e observar quais as falhas

    existentes nos sistemas, falhas estas que eventualmente possibilitam que atacantes se

    infiltrem na aplicao para usufruir de informao confidencial existente. Esta fase de

    execuo est divida em duas partes. A primeira envolve gerar workload sem considerar

    as injees de dados maliciosos, com o intuito de perceber quais so as respostas tpicas

    do Web Service. A segunda j implica a alterao de informao. Nesta fase so

    executados diferentes passos e em cada um deles focado um servio diferente. Cada

    passo contm tambm slots, responsveis por focar um parmetro especfico, sendo

    posteriormente usados para executar perodos de ataques. Em cada um destes perodos,

    so efetuados ataques a um dado parmetro da operao, onde substituda a

    informao vlida, por invlida, de modo a verificar se esta alterao vai causar uma

    reao no esperada na aplicao. Neste artigo conclui-se que possvel melhorar o

    estado da arte no que toca deteo de vulnerabilidades e que possvel o

    desenvolvimento de scanners mais eficientes do que os que esto disponveis

    comercialmente, realando a importncia desta temtica e o impacto que esta tem na

    segurana dos Web Services existentes.

    A principal limitao existente nos scanners deste tipo de testes, acaba por ser a mesma

    que nos testes de robustez, ou seja, a aplicao dos testes atravs do cliente, que acaba

    por ser a vertente mais segura do sistema. Na eventualidade de ser uma abordagem

    usada a partir da base de dados, possui a limitao de ter de se comprometer o contedo

    da base de dados para os testes poderem ser efetuados.

    2.4.2 Second-Order SQL Injection

    Este ataque bastante parecido com o ataque acima referido, com a diferena de que,

    neste ataque, os comandos SQL maliciosos so armazenados na base de dados, para

    serem executados mais tarde, em vez de serem executados naquele instante, como

    apresentado na Figura 2.7.

  • 15

    Figura 2.7 Exemplo de Second-Order SQL Injection.

    Neste exemplo, o ataque Second-Order SQL Injection ocorre da seguinte forma:

    supondo que existe um utilizador registado com o username = Pedro e password =

    admin. Considerando agora que ocorre um registo de um utilizador com o username =

    Pedro-- e password = hacker. Seguidamente, o utilizador com o username = Pedro--

    quer alterar a sua password. Neste momento, ele vai desencadear o ataque Second-

    Order SQL Injection.

    A query resultante de um pedido de alterao de password a seguinte:

    UPDATE users SET password = password_nova WHERE username =

    nome AND password = password_antiga;

    No entanto, neste caso, ao alterar a sua password, como se pode observar na Figura 2.7,

    o utilizador vai desencadear o ataque. O pedido de alterao de password vai resultar na

    seguinte query;

    UPDATE users SET password = hack_done WHERE username =

    Pedro - - AND password = hacker;

    Devido utilizao de --, o username a ser alterado vai ser o Pedro e visto ser

    interpretado como comentrio pelo SQL, tudo o que se encontra a seguir a estes

    caracteres, ignorado. Consequentemente, a comparao da password, j no vai ser

    feita, logo vai alterar a password do utilizador Pedro apesar de no ser este o utilizador

    que est a efetuar as alteraes. A implementao deste tipo de ataques envolve dois

    processos: armazenamento e ativao. O primeiro implica guardar todo o input do

    utilizador na base de dados para que seja utilizado posteriormente. J o processo de

    ativao, inclui o recolher da informao e sua concatenao com uma instruo SQL, a

    qual vai desencadear o ataque por Second-Order SQL Injection.

    Muitas das aplicaes Web Services, usam o tratamento correto dos dados ao inseri-los

    na base de dados, mas assim que estes se encontram armazenados, no so mais tratados

  • 16

    ou analisados para verificar se os dados so uma ameaa para a aplicao [32], logo,

    assume-se que o que est dentro da base de dados no uma ameaa. Desta forma

    permite-se que estes tipos de ataques sejam possveis quando a base de dados usa

    informao nela existente, como um input de uma query de uma pesquisa posterior. Esta

    forma de ataque uma prova de que deve existir tratamento de dados antes e depois da

    insero de informao em base de dados, ou seja, fazer o tratamento de dados quer

    sejam provenientes do utilizador ou da base de dados. Depois destes comandos SQL

    maliciosos se encontrarem armazenados, uma questo de tempo at serem usados pela

    prpria aplicao, provocando um ataque por SQL Injection. Este ataque requer mais

    conhecimentos em relao ao referido na Subseco 2.4.1, pois neste caso, o atacante

    tem de saber que valores usar, de modo a que se tornem mais tarde num ataque bem

    sucedido. Este ataque no facilmente detetado por scanners de segurana de

    aplicaes web porque estes servem para verificar falhas antes de os dados estarem na

    base de dados e no quando j esto inseridos. Existem vrias maneiras de diminuir a

    possibilidade de um ataque por Second-Order SQL Injection, uma delas a utilizao

    de consultas parametrizadas (prepared statements), onde os valores so passados

    usando parmetros SQL em vez de se inserir os dados de entrada do utilizador

    diretamente na consulta.

    Em [41], descrita em detalhe a tcnica de SQL Injection, apresentando vrios mtodos

    utilizados para fazer este tipo de ataque, incluindo, Second-Order SQL Injection, String

    without quotes, Lenght Limits e Audit Evasion, assim como problemas relacionados com

    a validao dos dados que so submetidos pelo utilizador. O autor mostra como podem

    ser feitos ataques deste tipo, apesar de serem tomadas algumas precaues para tentar

    contornar este problema, como por exemplo, ignorar as aspas isoladas. De qualquer

    forma, estas precaues no so suficientes para travar estes ataques, sendo que a

    melhor soluo apresentada consiste em rejeitar todo o input malicioso em vez de o

    alterar.

    Wei et al. [42], propuseram uma nova tcnica que permite evitar ataques que tenham

    como alvo Stored Procedures. Para a avaliar foi desenvolvido um prottipo, que foi

    testado numa base de dados em SQL Server 2005. Esta tcnica combina a anlise

    esttica do cdigo com validao em tempo de execuo com o objetivo de eliminar

    estes ataques. Foi usada, para experincia, uma base de dados protegida com este

    prottipo e outra sem estar protegida. Em ambos os casos foram feitos ataques de SQL

    Injection, incluindo ataques de Second-Order SQL Injection, os quais foram detetados

    pela tcnica referida. Os autores chegaram concluso que esta tcnica/ferramenta seria

    uma soluo para defender uma aplicao de ataques deste tipo.

    2.4.3 Preveno e Deteo de SQL Injection

    A OWASP (Open Web Application Security Project) [43] detalha alguns mtodos

    usados para combater ataques desta origem. Estes ataques ocorrem principalmente

    quando os programadores desenvolvem queries dinmicas que incluem input do

    utilizador. Uma boa prtica de programao obrigatria para ajudar no combate a este

    tipo de falhas, de maneira a que, quando o input do utilizador contenha SQL malicioso,

    a estrutura da query no seja modificada. O uso de prepared statements e/ou stored

    procedures parametrizadas em todas as intrues SQL, em vez das tpicas statements,

    um dos mtodos que permite tornar a aplicao mais segura e menos propcia a ataques

  • 17

    de SQL Injection. As stored procedures, visto que so compiladas antes do input do

    utilizador ser adicionado, fazem com que seja impossvel a alterao da instruo SQL

    pelo hacker. Outra sugesto dada a atribuio de privilgios que sejam o mais baixo

    possveis (least privilege), isto , se a aplicao necessita apenas de ler, ento ela deve

    ter apenas permisso para ler e no qualquer outra, que permita a alterao de

    informao na base de dados. O mau tratamento de excees outro motivo pelo qual o

    atacante consegue infiltrar-se no sistema com uma frequncia indesejvel. Excees que

    no so capturadas acabam por fornecer demasiada informao ao utilizador, dando a

    conhecer, inclusive, nomes de tabelas e nomes de procedimentos. O melhor mtodo

    referido pelo autor o uso de stored procedures e mesmo assim estas no so totalmente

    seguras. Seguem-se as queries parametrizadas e por fim as instrues SQL dinmicas.

    Resumindo, as melhores opes referidas para um aumento da segurana so:

    Uso de prepared statements (queries parametrizadas);

    Uso de stored procedures;

    Fazer o escape do input do utilizador antes de ser introduzido na query;

    Dar apenas as permisses necessrias para o caso em questo (least privilege);

    Fazer validao do input antes deste ser processado pela aplicao.

    Uma nova abordagem para detetar Second-Order SQL Injection atravs de uma soluo

    esttica e dinmica, proposta em [44]. O primeiro passo a anlise do cdigo a fim de

    detetar pontos vulnerveis na aplicao, seguindo-se uma sequncia de testes, com

    inputs maliciosos gerados, que vo averiguar se estas vulnerabilidades se confirmam.

    Neste trabalho explica-se igualmente o princpio de um ataque deste tipo e so

    estabelecidas definies formais sobre o mtodo apresentado, de modo a descobrir a

    ligao entre o processo de armazenamento e ativao do ataque. Na anlise ao cdigo

    feita uma procura pelas instrues SQL existentes incluindo os campos sobre a qual vai

    operar (nome da coluna), sendo depois extradas, usando expresses regulares que

    sirvam o mesmo propsito. Posteriormente, so aplicadas as definies acima referidas,

    seguindo-se a gerao da sequncia de testes, que est relacionada com o mapeamento

    da relao entre as instrues SQL e os pedidos de HTTP, tambm explicado nas

    definies formais apresentadas pelos autores. O passo seguinte consiste na gerao do

    input que ser usado para testar a aplicao, o que implica a injeo de dados maliciosos

    que vai alterar a semntica da instruo SQL original. Por fim, a fase de testes onde se

    vai incorporar os inputs maliciosos com a sequncia de testes, seguindo-se mais uma

    vez as definies formais j mencionadas. Estes testes so executados atravs de

    pedidos HTTP, na ordem da sequncia de testes. Caso o processo de armazenamento

    falhe no envio do primeiro pedido, o segundo j no enviado e segue-se para a

    prxima sequncia de testes. Se o input malicioso for guardado com sucesso na base de

    dados, o segundo pedido enviado, o qual vai revelar a existncia de uma

    vulnerabilidade, caso esta exista. Finamente, Lu Yan et al. concluem que o mtodo

    apresentado atravs da combinao das vantagens da anlise esttica e de testes

    dinmicos permite a deteo de vulnerabilidades no sistema e reduz os falsos positivos.

  • 18

    Como se pode constatar, pelo que j foi dito antes, os Web Services esto longe de

    estarem seguros, tendo em conta o elevado nmero de ataques assim como o nmero

    reduzido de scanners eficientes. Tendo em conta estes fatores, a elevada quantidade de

    Web Applications que contm vulnerabilidades tanto de robustez como de segurana,

    que comprometem a sua integridade, e a abordagem nica apresentada considerou-se

    pertinente a contribuio proposta nesta dissertao, considerando que o resultado da

    ferramenta ir ser uma mais-valia para a segurana dos Web Services existentes. Posto

    isto, seguidamente apresentada esta abordagem e toda a evoluo e modo de

    funcionamento da ferramenta desenvolvida.

  • 19

    Captulo 3 Metodologia e Abordagem

    Neste captulo so discutidas algumas abordagens relacionadas com a mesma temtica

    que servem de base a esta dissertao (Seco 3.1). Posteriormente, na Seco 3.2,

    feita a descrio dos testes criados, onde ainda apresentado o modelo de falhas, o

    perfil dos testes e a classificao dos mesmos.

    3.1 - Tcnicas para Injeo de Valores Invlidos ou Maliciosos

    Como definido inicialmente, o objetivo passou por testar a robustez e segurana de uma

    aplicao atravs da injeo de dados invlidos e maliciosos na mesma, de tal modo que

    vulnerabilidades existentes que possam ser usadas para ataques fiquem expostas para

    que as possamos corrigir. Para tais ataques poderem ser efetuados existem diversas

    abordagens que podem ser implementadas:

    Injeo de dados maliciosos atravs do input do cliente;

    Alterao da informao existente na base de dados;

    Alterao da informao diretamente na aplicao (servidor).

    A abordagem que recorre alterao do cliente consiste na injeo de dados

    maliciosos atravs do input do cliente [44]. Nesta abordagem, a origem dos ataques

    o cliente, que injeta dados maliciosos atravs dos inputs requeridos pela aplicao, de

    modo a tentar encontrar falhas no sistema para que as consiga explorar. Este tipo de

    ataques recorre ao uso de dados que consigam comprometer a segurana do sistema,

    contornando-a atravs da injeo de informao que o sistema no est espera, ou seja,

    injeo de dados que a aplicao no consegue tratar, no tem capacidade de filtrar.

    SQL Injection um dos mtodos usados neste tipo de ataques, onde o cliente injeta

    instrues SQL, em reas que no so direcionadas para tal, por exemplo, o uso de

    instrues SQL em formulrios de login um exemplo, como se pode verificar na

    Figura 2.6.

    Outra possibilidade a alterao da informao existente na base de dados [45]. Este

    tipo de abordagem est centrada na base de dados e nas informaes nela existentes.

    Normalmente, este mtodo recorre introduo de dados maliciosos diretamente na

    base de dados, ou seja, as tabelas da base de dados de uma aplicao so alteradas

    diretamente, havendo a insero de dados maliciosos, que permitam testar a robustez e

    segurana de uma aplicao. Para isto, parte-se do pressuposto que os campos

    modificados na base de dados vo ser usados futuramente.

    Atravs da alterao da implementao da aplicao (servidor) [46], recorrendo a

    modificaes feitas na mesma, como por exemplo, nos valores retornados pelas funes,

    tambm possvel comprometer a robustez/segurana da aplicao. Este mtodo

    envolve a criao de uma ferramenta interna implementada diretamente na aplicao

    que ir servir de apoio ao programador para testar a aplicao medida que esta seja

    desenvolvida. Exemplificando de forma sinttica, imagine-se que foi feita uma pesquisa

    base de dados e que a informao retornada chega aplicao, ento neste momento

    que vo ser feitas as alteraes. A aplicao em vez de ir buscar os valores que foram

    retornados pela base de dados, vai buscar valores maliciosos, como a uma tabela de

    testes, utilizando-os para realizar ento os testes de robustez e segurana. Resumindo,

    seria, por exemplo, pegar na abordagem elaborada e em vez de a usar numa verso

    alterada do JDBC, us-la diretamente na aplicao, alterando o cdigo desta.

  • 20

    Ao contrrio de todas as abordagens atrs referidas, a metodologia aqui apresentada no

    interfere nem altera o normal funcionamento do sistema, no existindo alteraes em

    clientes, em aplicaes, ou em bases de dados, como se pode observar na Figura 3.1.

    Figura 3.1 Funcionamento da tcnica, em Java, para injeo de valores invlidos e

    maliciosos.

    Esta abordagem surgiu da ideia de que qualquer mtodo usado para testar a segurana e

    robustez de uma aplicao no deve implicar alteraes diretas no funcionamento ou

    estrutura do sistema em questo, ou seja, no deve ser necessrio fazer alteraes ao

    Web Service para podermos executar os testes. Desta forma, a ferramenta est presente

    no sistema apesar de no se notar a sua presena, ou seja, a nica coisa que feita para a

    aplicao da ferramenta a substituio do driver JDBC entre a aplicao e a base de

    dados. Basicamente, todas as alteraes efetuadas ocorrem no meio da comunicao

    entre a base de dados e a aplicao, atravs de um componente middleware (JDBC). Em

    outras linguagens existem tambm componentes semelhantes que permitem realizar as

    mesmas funes [47].

    A implementao desta ferramenta acaba por ser alheia ao cdigo dos Web Services,

    no precisando de ser adaptada a cada sistema alvo para ser usada. Esta invisibilidade

    torna-se possvel graas ao conceito de Programao Orientada a Aspetos (POA) [46],

    mais especificamente ao AspectJ [47], que foi a primeira linguagem a ser desenvolvida,

    sendo a mais popular atualmente. Este conceito, POA, foca os problemas que, em

    Programao Orientada a Objetos no tm soluo apropriada, os chamados problemas

    de crosscutting que dizem respeito a cdigo que implementa funcionalidades

    secundrias e que usado em diversos pontos da aplicao, ou seja, cdigo que, em

    Programao Orientada a Objetos, no diz respeito ao comportamento do objeto em si,

    no fazendo parte da sua estrutura. Nesta dissertao foi usado o conceito de join point

    de POA, que tem como objetivo identificar os pontos da aplicao (e.g., mtodos) que

    devem ser abordados para fazer, ou no, alteraes e advice que corresponde ao cdigo

  • 21

    que vai ser executado quando estes join points so encontrados. Cdigo este que tem

    como finalidade adicionar mtodos, variveis ou neste caso a alterao do resultado

    esperado pela aplicao. Tendo em conta que um dos objetivos desta dissertao passou

    por desenvolver uma ferramenta que fosse o menos evasiva possvel, o recurso a esta

    linguagem, que especializada em POA, foi obrigatrio. Esta permitiu tambm que a

    ferramenta proposta fosse automatizada de modo a que no fosse preciso adapt-la para

    cada base de dados.

    O funcionamento da abordagem referida bastante simples. Primeiro e antes de tudo,

    introduzida a ferramenta, entre a aplicao e a base de dados, substituindo o driver

    JDBC existente, como j foi referido. Posteriormente, o cliente faz as transaes e

    pedidos normais com a aplicao, a qual vai aceder base de dados para realizar os

    pedidos efetuados. Neste acesso, os pedidos vo passar pela ferramenta, que vai aceder

    base de dados normalmente, fazendo as pesquisas necessrias e extraindo os

    resultados. No final do processamento do pedido feito pelo cliente, entra em ao a

    abordagem implementada. Com a ferramenta criada, no momento em que os resultados

    esto prestes a ser transmitidos de novo para a aplicao, estes vo ser alterados e

    substitudos, conforme o teste a ser aplicado. Aps a sua substituio, os dados so

    enviados para a aplicao, como se fossem os resultados das pesquisas requeridas por

    esta. Esta alterao de resultados vai possibilitar a verificao da existncia de

    problemas de robustez ou segurana e em que circunstncias eles surgem, de tal modo,

    que se possa proceder sua correo futuramente.

    3.2 Abordagem para Avaliao de Robustez e Segurana

    Nesta seco so abordados os Testes de Robustez e Segurana desenvolvidos, usados

    pela ferramenta implementada. Nos testes recorre-se ao uso de dados predefinidos que

    exploram as falhas existentes nos Web Services em cada acesso base de dados. Nestes

    podem ser consideradas quatro fases, como se pode observar na Figura 3.2:

    Figura 3.2 Fase de testes da ferramenta.

    1) Preparao dos testes: configurao do sistema onde vo ser feitos os testes, ou seja, configurao da aplicao, do cliente, da base de dados e substituio do

    driver JDBC pela ferramenta criada.

    2) Recolha de Informao: recolha da informao que corresponde ao normal funcionamento da aplicao, cujo objetivo observar o comportamento normal

  • 22

    do Web Service de modo a obter a estrutura da aplicao para os testes poderem

    ser aplicados. Esta estrutura corresponde aos pontos de acesso base de dados

    existentes no cdigo, ou seja, vai ter o papel de um mapa, para a aplicao saber

    onde vai ter de efetuar os testes, de modo a verificar se existem vulnerabilidades

    naquela localizao em especfico. importante referir que esta recolha

    efetuada em ambiente e workload controlados. Isto significa que todos os testes

    vo ser executados num ambiente configurado pelo analista, tendo a

    possibilidade de aumentar ou diminuir o volume de transaes no sistema. Esta

    fase decorre durante um tempo predefinido, no havendo quaisquer alteraes

    ou modificaes no normal funcionamento do servio;

    3) Execuo dos Testes de Robustez/Segurana: aplicao dos testes, atravs da injeo de parmetros invlidos, de modo a descobrir problemas existentes no

    sistema;

    4) Caraterizao do Servio: classificao do servio atravs dos resultados obtidos a partir da introduo de testes de robustez no normal funcionamento da

    aplicao (e.g., o servio lana uma exceo na existncia de um null pointer,

    logo foi necessrio avaliar quais os danos causados e quais as consequncias

    para a aplicao). Mais uma vez importante referir que este normal

    funcionamento da aplicao corresponde a uma simulao do workload da

    mesma no seu dia-a-dia, podendo haver alteraes para aumentar ou diminuir o

    congestionamento do sistema para simular todos os cenrios possveis.

    As fases apresentadas anteriormente devem ser seguidas de uma forma sequencial. Estes

    passos podem tambm ser usados por qualquer ferramenta de testes de robustez desde

    que seja usada a mesma abordagem aqui descrita.

    1) Preparao dos Testes

    Inicialmente, para a preparao dos Testes, necessrio configurar todos os

    componentes presentes no sistema que vai ser testado, de modo a que tudo esteja

    devidamente preparado para no existirem falhas ao nvel da estruturao e

    configurao do sistema. Este um passo importante para que os resultados dos testes

    executados sejam precisos. Existem alguns requisitos que devem ser cumpridos para

    que a ferramenta funcione tais como, a linguagem da aplicao sob teste tem ser Java e

    conter a verso 6 do Java EE com a verso Servlet 3.0 tendo em conta que a ferramenta

    utiliza filtros HTTP que necessitam de deteo automtica da parte do servidor,

    disponvel apenas na verso do Servlet acima referida. Depois dos requisitos se

    verificarem, necessria a presena de um ou mais clientes que executam os servios da

    aplicao. preciso configurar tambm a aplicao que contem os servios referidos e a

    base de dados que contem toda a informao existente. ainda necessrio considerar a

    existncia de um servidor capaz de alojar todo este sistema. Por fim, deve ser feito o

    deployment da ferramenta, sendo esta um ficheiro do tipo jar. A mesma includa entre

    a aplicao e a base de dados, substituindo o jar do driver JDBC existente pela

    ferramenta com a qual os testes vo ser realizados.

    Aps a preparao e configurao de todos os componentes procede-se fase detalhada

    em seguida.

  • 23

    2) Recolha de Informao

    Antes de se proceder execuo dos testes existem alguns detalhes que requerem

    ateno especial. Esta fase corresponde ao normal funcionamento da aplicao, onde

    apenas se tem o papel de observador, assistindo simplesmente ao seu desempenho sem

    esta estar sujeita a quaisquer intervenes externas. O cliente possui um papel crucial

    nesta fase, tendo em conta que toda a informao necessria para a construo do mapa

    provm do workload gerado pelos pedidos do mesmo, sendo tambm importante para a

    durao que a mesma vai ter, j que esta est relacionada com o nmero de pedidos que

    o cliente faz ao servidor, ou seja, o tempo que esta fase vai durar corresponde ao

    nmero introduzido numa varivel existente na ferramenta. Este nmero vai

    corresponder ao nmero mximo de pedidos recebidos do cliente at ocorrer a transio

    para a fase seguinte. Exemplificando, se definirmos o valor vinte como mximo, a fase

    de aprendizagem vai durar at o cliente efetuar vinte pedidos aplicao. Para controlar

    o momento em que este valor atingido existe uma outra varivel que incrementada

    sempre que a ferramenta deteta um pedido novo do cliente. Esta deteo feita atravs

    de filtros HTTP, que sempre que intercetam uma chamada para um dos servios,

    verificam se o nmero mximo de pedidos do cliente corresponde ao nmero mximo

    configurado at mudar de fase. Esta etapa indispensvel para os testes elaborados, pois

    recolhida informao crucial sobre a aplicao e a sua estrutura. Com esta possvel

    criar um mapa da aplicao para permitir a execuo dos testes. Este composto por

    todos os pontos de acesso base de dados existentes na aplicao. A construo deste

    mapa feita da seguinte forma: em tempo de execuo, a ferramenta vai guardar as

    posies em que existem chamadas base de dados. Este armazenamento de

    informao vai ser feito atravs do AspectJ e StackTrace. O AspectJ vai intercetar todas

    as chamadas dos mtodos que fazem pedidos base de dados e neste momento, e

    enquanto se encontrar na fase de aprendizagem, a ferramenta vai usar o StackTrace para

    guardar a linha e nome do ficheiro onde esta chamada foi feita. Este processo efetuado

    para todos os pontos de acesso pelos quais a aplicao passa durante esta fase, criando

    desta forma, o referido mapa.

    3) Execuo dos Testes

    Nesta subseco feita uma explicao de tudo o que est relacionado com a aplicao

    dos testes, tanto de robustez como de segurana, no Web Service em avaliao. Na

    Figura 3.3 est representado o funcionamento do sistema, quando sujeito ferramenta

    de testes em questo.

  • 24

    Figura 3.3 Funcionamento de um sistema sujeito ferramenta de testes.

    O elemento que requer mais ateno a ferramenta de testes, que vai atuar como um

    driver JDBC modificado e fazer a ligao entre a aplicao e a base de dados do Web

    Service. Esta ferramenta vai receber as pesquisas SQL enviadas pela aplicao e os

    resultados destas pesquisas da base de dados. Estes resultados vo ser alterados pela

    ferramenta com o objetivo de procurar vulnerabilidades na aplicao. Estes vo ser

    substitudos por dados invlidos existentes na Tabela 3.1. Depois de modificados, vo

    ser transmitidos de novo para a aplicao. Este o funcionamento base da aplicao

    para todo o tipo de testes excetuando alguns pormenores que sero referidos

    posteriormente aquando da explicao do funcionamento individual de cada teste.

    importante realar que com este tipo de abordagem, o cdigo fonte desta no precisa de

    ser do conhecimento do analista para se poderem executar os testes. Tanto do lado do

    servidor como do cliente, no necessrio o seu conhecimento.

    i. Testes de Robustez I e II

    Estes testes envolvem a manipulao de parmetros, com o objetivo de injetar dados

    invlidos contra os quais a aplicao pode no estar protegida. A diferena dos Testes

    de Robustez I para os Testes de Robustez II baseia-se no facto de que nos ltimos, s

    feita uma injeo por cada pedido do cliente, enquanto nos primeiros esta injeo ocorre

    em todas as chamadas base de dados. Esta manipulao de dados referida

    anteriormente, obrigou criao de algumas regras que devem ser seguidas nesta

    abordagem. importante realar que estas regras visam atingir as condies de limite

    dos tipos de dados, que so por norma a origem dos problemas no que toca robustez

    das aplicaes, visto elas no fazerem a validao deste tipo de situaes. Seguem-se

    exemplos de situaes contra as quais as aplicaes no costumam estar protegidas:

  • 25

    Valores mximos e mnimos vlidos correspondentes a um determinado tipo de dado (valor mximo possvel para um parmetro e valor mnimo possvel para

    um parmetro);

    Valores que excedem o mximo e mnimo possvel para aquele tipo de dados (valor mximo possvel para um parmetro mais um, valor mnimo possvel para

    um parmetro menos um);

    Valores a null e vazios (strings nulas ou vazias);

    Valores com caratersticas especiais (carateres non-printable em strings)

    Valores que causam problemas de data type overflow (adicionar carateres a uma string para que ultrapasse o seu tamanho mximo)

    Valores vlidos com dados invlidos ( usar datas invlidas)

    Uso de valores maliciosos com o objetivo de explorar potenciais falhas de segurana no sistema [50][51], como por exemplo SQL Injection, um exemplo

    de ataque frequentemente utilizado contra Web Services [52].

    As regras propostas na Tabela 3.1 esto definidas para cada tipo de dados e foram

    baseadas em problemas de validao apresentados acima e em artigos e trabalhos sobre

    testes de robustez em servios apresentados anteriormente [19][20][53].

    Tipo de

    Dados

    Nome do Teste Mutao de Parmetro

    Number

    int

    float

    double

    short

    long

    BigDecimal

    Nmero Menos Um

    Nmero Um

    Nmero Zero

    Adicionar Um Nmero

    Subtrair Um Nmero

    Nmero Mximo Positivo

    Nmero Mximo Negativo

    Nmero Mximo Positivo Menos Um

    Nmero Mximo Negativo Mais Um

    Substituir por -1

    Substituir por 1

    Substituir por 0

    Adicionar 1

    Subtrair 1

    Substituir pelo nmero mximo positivo

    Substituir pelo nmero mximo negativo

    Substituir pelo nmero mximo positivo menos um

    Substituir pelo nmero mximo negativo mais um

    String

    String Nula

    String Vazia

    String Predefinida

    String No Imprimvel

    Adicionar String No Imprimvel

    String AlfaNmerica

    String Maliciosa

    Substituir por valor nulo

    Substituir por string vazia

    Substituir por string predefinida

    Substituir por String com caracteres no imprimveis

    Adicionar caracteres no imprimveis string

    Substituir por string alfanumrica

    String maliciosa predefinida

    Date

    Data Nula

    Data Mxima Mais Um

    Data Mxima Menos Um

    Adicionar 100 Data

    Subtrair 100 Data

    Data dia-ms-ano:

    29-02-1984

    31-04-1998

    01-13-1997

    00-12-1994

    31-06-1998

    32-08-1993

    31-12-1999

    01-01-2000

    Substituir por valor nulo

    Substituir por data mxima vlida no parmetro mais um dia

    Substituir por data mxima vlida no parmetro menos um dia

    Adicionar 100 anos data

    Subtrair 100 anos data

    Substituir por datas com o seguinte formato: dd-MM-yyyy

    Substituir pela seguinte data invlida: 29-02-1984

    Substituir pela seguinte data invlida: 31-04-1998

    Substituir pela seguinte data invlida: 01-13-1997

    Substituir pela seguinte data invlida: 00-12-1994

    Substituir pela seguinte data invlida: 31-06-1998

    Substituir pela seguinte data invlida: 32-08-1993

    Substituir pela seguinte data invlida: 31-12-1999

    Substituir pela seguinte data invlida: 01-01-2000

  • 26

    Boolean

    Boolean predefinido

    Resultado Inverso Boolean

    Substituir por valor predefinido

    Substituir por resultado inverso

    Time

    Hora nula

    Hora Mxima Mais Um

    Hora Mnima Menos Um

    Adicionar 24 Horas

    Subtrair 24 Horas

    Hora hh-mm-ss:

    17-02-61

    16-04-00

    01-00-10

    03-61-12

    25-08-30

    00-08-50

    25-61-61

    00-00-00

    Substituir por valor nulo

    Substituir por hora mxima vlida no parmetro mais uma hora

    Substituir por hora mnima vlida no parmetro menos uma hora

    Adicionar 24 horas ao tempo

    Subtrair 24 horas ao tempo

    Substituir por hora com o seguinte formato: hh-mm-ss

    Substituir pela seguinte hora invlida: 17-02-61

    Substituir pela seguinte hora invlida: 16-04-00

    Substituir pela seguinte hora invlida: 01-00-10

    Substituir pela seguinte hora invlida: 03-61-12

    Substituir pela seguinte hora invlida: 25-08-30

    Substituir pela seguinte hora invlida: 00-08-50

    Substituir pela seguinte hora invlida: 25-61-61

    Substituir pela seguinte hora invlida: 00-00-00

    TimeStamp

    Data/Hora nulos

    Hora Mxima Mais Um

    Hora Mnima Menos Um

    Adicionar 24 Horas

    Subtrair 24 Horas

    Tempo dia-ms-ano hh-mm-ss:

    29-02-1984 17-02-61

    31-04-1998 16-04-00

    01-13-1997 01-00-10

    00-12-1994 03-61-12

    31-08-1998 25-08-30

    32-08-1993 00-08-50

    31-12-1999 25-61-61

    01-01-2000 00-00-00

    Substituir por valor nulo

    Substituir por hora mxima vlida no parmetro mais uma hora

    Substituir por hora mnima vlida no parmetro menos uma hora

    Adicionar 24 horas ao tempo

    Subtrair 24 horas ao tempo

    Substituir tempo com seguinte formato: dd-MM-yyyy hh-mm-ss

    Substituir pela seguinte data/hora invlida: 29-02-1984 17-02-61

    Substituir pela seguinte data/hora invlida: 31-04-1998 16-04-00

    Substituir pela seguinte data/hora invlida: 01-13-1997 01-00-10

    Substituir pela seguinte data/hora invlida: 00-12-1994 03-61-12

    Substituir pela seguinte data/hora invlida: 31-06-1998 25-08-30

    Substituir pela seguinte data/hora invlida: 32-08-1993 00-08-50

    Substituir pela seguinte data/hora invlida: 31-12-1999 25-61-61

    Substituir pela seguinte data/hora invlida:01-01-2000 00-00-00

    Tabela 3.1 Tabela de Testes de Robustez I e II.

    As regras referentes a TimeStamp, por exemplo, foram criadas de raiz assim como

    Boolean e Time. Como foi j mencionado, algumas regras j existiam e foram adaptadas

    para esta ferramenta em questo, como o caso do grupo Date, Numbers e Strings. De

    modo a garantir a total cobertura da aplicao em relao s suas falhas, foram definidas

    algumas regras em relao ao procedimento dos testes:

    Todas as operaes provenientes do Web Service devem ser testadas;

    Para cada parmetro, todos os testes representados na Tabela 3.1 devem ser aplicados, ou seja, por exemplo, considerando que o tipo de parmetro

    corresponde a um nmero, todos os testes existentes na tabela relacionados com

    nmeros devem ser aplicados;

    Cada teste pode ser repetido diversas vezes para cada caso em especfico, para verificar que o comportamento resultante sempre o mesmo. Este nmero de

    repeties configurvel, de tal modo que cabe ao analista escolher o nmero de

    vezes que quer executar cada teste;

    A fase de testes apenas termina quando todos os pontos de acesso base de dados forem sujeitos a esta injeo maliciosa ou a aplicao termine de forma

    abrupta (crash);

  • 27

    A transio dos Testes de Robustez I para Testes de Robustez II acontece somente quando forem testados todos os pontos de acesso base de dados.

    O nmero de repeties dos testes depende do conhecimento que o analista em questo

    tem acerca do servio e da cobertura que estes conseguiram oferecer na primeira

    execuo.

    Durante a execuo dos testes de robustez, existem trs cenrios diferentes que podem

    ser criados:

    Testes de Robustez I: a ferramenta executa apenas os testes de Robustez I;

    Testes de Robustez II: a ferramenta executa apenas os testes de Robustez II;

    Testes de Robustez I e II: a ferramenta executa os testes de Robustez I e II.

    A ferramenta interceta todas as operaes feitas pela aplicao base de dados, como

    est representado na Figura 3.3. Quando a ferramenta recebe os resultados da base de

    dados, verifica a estrutura adquirida na fase de Recolha de Informao de modo a

    averiguar se aquele caso j sofreu uma alterao anteriormente. No se tendo verificado

    esta alterao, procede-se marcao da flag existente, caso contrrio continua a

    execuo. Esta sinalizao vai permitir ferramenta saber quando j testou todas as

    entradas para a base de dados existentes na aplicao, de modo a terminar a fase de

    testes, se o analista quiser executar apenas os Testes de Robustez I, ou poder avanar

    para os Testes de Robustez II, o que acaba por ser um mtodo de controlo na transio

    para o prximo tipo de testes, assim como garantir total cobertura dos testes sob o

    sistema. Depois de fazer esta verificao no mapa adquirido, acede aos casos de teste

    representados na Tabela 3.1, e dependendo do tipo de dados em questo substitui a

    informao correta por dados invlidos retirados da tabela mencionada. Depois desta

    substituio ser feita, os resultados so reencaminhados para a aplicao. importante

    referir que nesta fase, todas as operaes feitas que requerem o acesso base de dados

    vo ver os seus resultados alterados, ou seja, a ferramenta vai alterar todos os resultados

    das chamadas base de dados. Apesar da posio j estar marcada como tendo sido

    sujeita a testes, no caso de Robustez I, os valores so sempre alterados. O aumento do

    nmero de testes pode resultar numa maior probabilidade de serem detetados problemas

    no sistema.

    O momento em que feito o restauro do sistema tambm relevante para o resultado

    final dos testes, tendo em conta que os resultados obtidos, fazendo o restauro depois dos

    Testes de Robustez I ou depois dos Testes de Robustez II, vai ser diferente. Isto deve-se

    ao facto de a acumulao de injees causar a ocorrncia de mais situaes de falhas,

    logo, executar os testes com a base de dados limpa ou comprometida, vai afetar o

    resultado final dos testes. Para cobertura do maior nmero de cenrios possvel

    aconselhvel a aplicao de ambas as situaes.

    Como j foi dito anteriormente, a diferena dos Testes de Robustez I para os Testes de

    Robustez II baseia-se no facto de que nos ltimos, s feita uma alterao por cada

    invocao operao do servio, isto , por cada vez que o cliente executa uma

    operao no servidor, a ferramenta, durante esta fase, vai apenas alterar um valor,

    marcando a flag no mapa, tal como nos testes anteriores, para que neste caso, no volte

    a alterar aquele valor quando a operao for executada. Assim que aquela posio no

    mapa marcada, a ferramenta no volta a alterar o valor daquela chamada base de

  • 28

    dados, mesmo que esta seja acedida novamente. Visto que, o programa s cessa os

    testes, aquando da marcao de todas as flags existentes no mapa ou de uma paragem

    inesperada do sistema (crash), garante-se, deste modo, total cobertura dos mesmos sob a

    aplicao, assegurando assim, que todos os possveis pontos de vulnerabilidade do

    sistema, so testados, isto considerando que o workload aplicado permite que a

    ferramenta detete a localizao de todos os pontos de acesso base de dados. Na

    eventualidade do workload configurado no ser o suficiente para construir o mapa de

    toda a aplicao, esta cobertura no pode ser assegurada. Consequentemente, e

    realando novamente que todos os pontos de acesso base de dados so detetados, a

    segurana do sistema garantida, para os testes aplicados, sempre que o resultado dos

    testes confirme que no existe nenhuma falha, ou que o sistema vulnervel, caso o

    resultado revele que existem violaes, na presena de certos elementos malicios