Narcísio José Mula
Testes de Segurança de Web Services a partir de Padrões de Ataques Representados em Modelos de Estados
CAMPINAS 2018
Narcísio José Mula
Testes de Segurança de Web Services a partir de Padrões de Ataques Representados em Modelos de Estados
Orientadora: Profa. Dra. Eliane Martins
CAMPINAS 2018
Dissertação apresentada ao Instituto de Computação da Universidade Estadual de Campinas como parte dos requisitos para a obtenção do título de Mestre em Ciência da Computação
Este exemplar corresponde à versão final da dissertação defendida por Narcísio José Mula e orientada pela Profa. Dra. Eliane Martins
BANCA EXAMINADORA
Profa. Dra. Eliane Martins (Presidente)
_____________________________________________________
Prof. Dr. Alexandre Melo Braga (Membro)
______________________________________________________
Profa. Dra. Maria de Fátima Mattiello Francisco (Membro)
_______________________________________________________
A ata da defesa, assinada pelos membros encontra-se disponível no SIGA/ Sistema de Fluxo de Dissertação/Tese e na Secretaria do Programa da Unidade.
Dedicatória
Aos meus filhos: Jany, Seny e ÂmelaAgradecimentos
Aos meus pais Deolinda e José por me terem dado a vida. Estarão sempre no meu coração, aos meus irmãos pelo carinho e por sempre acreditarem que tudo vai dar certo. Geraldo, Nélson, Dioclência, vocês são especiais. Aos tios Jaime, Hilário, Adolfo e Sérgio. À Suzete Nhanala, minha namorada, os meus especiais agradecimentos
Universidade Pedagógica de Moçambique pelo seu apoio, Universidade Estadual de Campinas pela oportunidade e em especial ao Instituto de Computação por me ter aceite no seu curso.
À Prof. Eliane Martins pela paciência e por acreditar no trabalho em todos os momentos. Aos Professores: Paulo Licios, Nelson Fonseca, Ariadne Carvalho, André Santachê, Luiz Bittencourt, Heiko Hornung e Flaivo Miyazawa.
Ao Prof. Nuno Antunes da Universidade de Coimbra pela colaboração com a sua ferramenta e sua máquina virtual wsvd-bench.
A todos professores de diversas disciplinas que frequentei no Instituto de Computação. Aos Srs Ernesto Chambisse, Sandra Duvane, Pedro Bila, Joaquim Junior, Pedro Macuacua, Belivia Chemane, Roberto Macuacua, Ana Verdial, Rodolfo Salgado.
Aos colegas moçambicanos da Unicamp: Izidro, Júlio, Dércia, Osvaldo, António, Macaringue, Óscar, Carlos e Ótis.
Resumo
Serviços Web (ou WS, do inglês web service) são muito utilizados por empresas, porque permitem reutilizar sistemas existentes para compor novas aplicações. Por serem elementos-chave dos sistemas de muitas empresas, a segurança de WS é um aspecto importante. Com o objetivo de encontrar uma forma de testar a segurança de serviços web que tenham uma elevada taxa de cobertura e uma baixa taxa de falsos positivos, nesta dissertação nós utilizamos uma técnica baseada em modelo a partir da descrição de ataques. Desta descrição, em língua natural, é obtido o modelo de estados que representa o comportamento do atacante, representando cada passo realizado ou projetado por ele.
O método, designado como Test WS, foi baseado em um método existente. Após adequá-lo às nossas necessidades de teste, usamo-lo para testar 21 serviços Web em busca de vulnerabilidades de SQL Injection e Cross Site Scripting. Os dados de entrada foram selecionados tendo em conta cada variedade destes dois tipos de ataque.
Apresentamos também uma discussão, comparando os resultados da nossa técnica com outras, mencionadas no trabalho, mostrando também os pontos fortes e fracos do método.
Abstract
Web services (or WS) are widely used by companies because they allow reusing existing systems to compose new applications. Because they are key elements of many enterprise systems, WS security is an important aspect.
To find a way to test the security of web services that have a high coverage rate and a low rate of false positives, in this dissertation we use a technique based on the description of attacks. From this description, in natural language, the state model is obtained that represents the attacker's behavior, representing each step realized or designed by him.
The method, called Test WS, was based on an existing method, tailored to our testing needs, and we used it to test 21 Web services for SQL Injection and Cross Site Scripting vulnerabilities. The input data were selected considering each variety of these two types of attack.
We also present a discussion, comparing the results of our technique with others, mentioned in the paper, also showing the strengths and weaknesses of the method.
Lista de Figuras
Figura 1: Arquitectura de Web Service [3] ... 18
Figura 2: Pilha de Protocolos de Web Sevice [11] ... 19
Figura 3: Estrutura de uma mensagem SOAP ... 20
Figura 4 : Requisição (Mensagem) SOAP e Resposta ... 21
Figura 5: SQL na tela de Login ... 27
Figura 6: Exemplo de um ataque XSS... 31
Figura 7: Funcionamento do XSS Refletido [23]. ... 33
Figura 8:Funcionamento de XSS armazenado [23]. ... 34
Figura 9: Funcionamento do DOM-based XSS [23]. ... 35
Figura 10: Exemplo de Caixa Preta ... 39
Figura 11: Exemplo de um teste feio com ZAP (teste de caixa preta) ... 40
Figura 12: Exemplo de Análise de Código com FindBugs ... 41
Figura 13: Taxonomia de Testes Baseados em Modelo. Fonte: [35] ... 42
Figura 14: Taxonomia de MBST. Fonte: [8] ... 44
Figura 15: Exemplo de um Padrão de Ataque ... 52
Figura 16: Exemplo do Modelo de Atacante. Fonte: [7] ... 54
Figura 17: Procedimento para realização dos testes de segurança. ... 59
Figura 18: Resposta de Mensagem SOAP sem vulnerabilidade de SQLI. ... 67
Figura 19: Resposta de Mensagem SOAP com vulnerabilidade de SQLI. ... 68
Figura 20: Resultado Sign WS, Test WS e VS... 71
Figura 21: Resposta de Mensagem SOAP sem XSS encontrado ... 72
Lista de Tabelas
Tabela 1:Subelementos de Fault ... 22
Tabela 2: Conceitos Sobre Testes ... 38
Tabela 3: Classificação dos trabalhos relacionados segundo a Taxonomia de Felderer et al [8] ... 50
Tabela 4: Descrição dos Serviços usados como experimento ... 60
Tabela 5: Exemplo de Entradas SQLI ... 63
Tabela 6: Exemplos de Entradas XSS ... 63
Lista de Códigos
Código 1: Exemplo de um procedimento armazenado ... 30 Código 2: Exemplo de DOM based ... 35 Código 3: Exemplo de Código de Implementação do Connect ... 64
Lista de Siglas
HTTP...Hipertext Transfer Protocol HTML...Hipertext Markup Language XML………. eXtensible Markup Language SQL...Structured Query Language URL...Uniform Resource Locator HTTPS...Hipertext Transfer Protocol SMTP...Simple Mail Transfer Protocol FTP...File Transfer Protocol
WSDL...Web Services Description Language
UDDI...Universal Description, Discovery and Integration XSD………XML Schema Definition
Índice
Dedicatória ... 18 Agradecimentos ... 19 Resumo ... 20 Abstract ... 21 Lista de Figuras ... 22 Lista de Tabelas ... 23 Lista de Códigos ... 24 Lista de Siglas ... 25 1.Introdução ... 14 1.1 Contexto ... 14 1.2. Problema ... 15 1.3. Objetivo ... 15 1.4. Contribuição ... 16 1.5. Organização da dissertação ... 16 2. Referencial Teórico... 17 2. 1. Serviços Web ... 172.1.1. Arquitetura Orientada a Serviços ... 17
2.1.2. Pilha de Protocolos de WS ... 19
2.1.4. SOAP ... 20
2.1.5. Representational State Transfer (REST) ... 22
2.2. Segurança de Informação... 24
2.2.1. Conceitos de Segurança de informação ... 24
2.2.2. Entraves à Segurança da Informação ... 25
2.2.3. Vulnerabilidades mais comuns em Serviços Web ... 26
2.2.4. Técnicas de Detecção de Vulnerabilidades ... 35
2.3. Testes ... 36
2.3.1. Técnicas de Teste ... 39
2.3.2. Testes Baseados em Modelo ... 41
2.4. Testes de segurança ... 43
2.4.1. Classificação dos Testes de Segurança ... 43
2.4.2. Testes de Segurança Baseados em Modelo ... 44
3. Revisão trabalhos relacionados ... 46
3.2. Teste de segurança de ws ... 49
3.3. Comparativo entre eles e o trabalho que foi feito ... 49
4. Teste de segurança usando Padrões de ataque ... 51
4.1. Padrão de Ataque ... 51
4.2. Modelo de Estado ... 52
4.3. Descrição das interfaces ... 54
4.4. Descrição dos valores maliciosos de entrada... 55
4.5. Análise de vulnerabilidades ... 56
4.5.1. Regras para detecção de vulnerabilidades de SQLI ... 56
4.5.2. Regras para XSS ... 57
5. Procedimento para os testes de segurança ... 59
5.1. Descrição dos serviços testados ... 59
5.2. Identificação dos objetivos dos testes ... 61
5.3. Escolha do tipo de ataques ... 61
5.4 Modelagem do atacante ... 62
5.5. Descrição dos dados maliciosos de entrada ... 62
5.6. Codificação ... 63
5.7. Execução dos testes ... 64
6. Avaliação da proposta ... 66
6.1. Resultados da detecção de SQLI ... 67
6.1.1. Respostas às questões QP1 e QP2 ... 69
6.1.2. Resposta a QP3 ... 71
6.2. Resultados da detecção de XSS ... 72
6.3. Discussão e lições aprendidas ... 74
7. Conclusão ... 75
1.Introdução
Nesta dissertação abordamos o problema de testes de segurança em web services com recurso a um método de testes de penetração baseado em modelo. Para levar a cabo o nosso objetivo, investigamos os métodos de teste baseados em modelo de forma a compreender como foram aplicados em outros problemas e domínios, como por exemplo nas aplicações web; em seguida estudamos como adaptá-los ao nosso problema, nomeadamente um cenário de web services. Finalmente aplicamos um método de testes baseado em modelo de estado que representam padrões de ataques e avaliamos sua efetividade na detecção de vulnerabilidades um ambiente de web service. Realizamos uma comparação entre os resultados encontrados através da aplicação do nosso método a um benchmarking, com os resultados de algumas ferramentas disponiveis de testes de segurança.
1.1 Contexto
Existe na literatura vários estudos e relatórios que mostram que a segurança de aplicações web pode ser questionada [1], [2] e, atualmente muitas aplicações web recorrem a um recurso importante para trocar dados e informações entre si: os web services (ws). Os ws permitem que os aplicativos sejam integrados de forma mais rápida, fácil e menos dispendiosa, tirando benefício do facto de que a integração ocorre no nível mais alto da pilha de protocolos, flexibilizando a ligação entre funções de negócios [3]. O uso de um WS se verifica em diversos setores ou tipos de aplicativos: indústrias de entrega de pacotes, processamento de pagamentos eletrônicos, serviços bancários e financeiros, compras de varejo. É usada em quase todas as áreas desde transportes, telecomunicações, saúde, educação. Além disso, constitui a base fundamental da computação orientada a serviços [4].
Estes serviços sofrem de vários tipos de vulnerabilidades, o que pode levar a divulgação indevida de informações de usuários, destruição ou modificação de dados ou do banco de dados, entre outras consequências. Um exemplo demonstrativo dos problemas de segurança dos ws são os resultados apresentados no artigo de Mouli e Jevitha [1], no qual, a partir da análise de diversos trabalhos constata-se que os serviços web, tal como as aplicações web têm problemas com diversos tipos de ataques e vulnerabilidades, tais como: Cross Site Scripting, XpathInjection, SQL Injection, Spoofing, Negação de Serviço, XML Injection e Man In The Middle. Isto acontece porque muitas vezes os desenvolvedores preocupam-se mais com a funcionalidade do sistema do que com aspectos relacionados com a segurança
[2] e também devido a natural dificuldade de garantir que um sistema seja desenvolvido 100% livre de bugs.
Para minimizar a ocorrência desses problemas, diferentes métodos podem ser aplicados, entre eles: análise estática de código e testes de penetração. Análise estática de código, como o nome indica, analisa o código fonte de uma aplicação com o objetivo de encontrar defeitos [5]. Esta técnica é considerada de caixa-branca, porque a estrutura interna do sistema é conhecido e pode ser realizada manual ou automaticamente através do uso de ferramentas. Teste de penetração é um método de verificação no qual a aplicação é analisada do ponto de vista externo numa abordagem de caixa-preta [5]. Esta abordagem é geralmente realizada com auxílio de ferramentas, submetendo-se o sistema a diversas entradas maliciosas com o objetivo de detectar vulnerabilidades.
1.2. Problema
Há uma grande variedade de ferramentas e metodologias que servem para auxiliar os desenvolvedores e testadores a identificar vulnerabilidades de segurança de software. No entanto nessas soluções muitas vezes não são de muita ajuda devido ao elevado número de falsos negativos e falsos positivos [2], [6]. Ou seja, muitas vezes não reportam vulnerabilidades existentes ou podem emitir um alarme falso, isto é, reportar a presença de uma vulnerabilidade onde ela não existe. Ademais, algumas ferramentas desenvolvidas para aplicações web podem não ser aplicáveis para testar web services, por causa da diferença de tecnologia usada para os dois tipos de produtos. Isto nos remete ao ponto 1.3, onde apresentamos o objetivo do trabalho que realizamos.
1.3. Objetivo
Tendo como base o que foi exposto nos pontos 1.1 e 1.2, o objetivo deste trabalho é: aplicar o método de testes baseados em modelo de estados representando padrões de ataques para testar serviços web. Para avaliar a sua efetividade, isto é, se o método ajuda a detectar vulnerabilidades em web services, é feita a comparação entre os resultados exibidos pelo método aplicado neste trabalho com outros métodos implementados em ferramentas existentes. Mais especificamente, aplicamos a metodologia de testes baseado em padrões de ataques proposta por [7] em um benchmarking de ws para avaliar a presença ou não de vulnerabilidades de SQL Injection e Cross Site Scripting. A seção 1.4 mostra as contribuições desta dissertação.
1.4. Contribuição
As contribuições deste trabalho são as seguintes:
• Uma apresentação sobre os conceitos de serviços web, segurança de informação e teste de software.
• Uma breve revisão das de trabalhos sobre testes de segurança baseados em modelo e uma comparação de trabalhos de testes baseados em modelo de acordo com a taxonomia de Felderer [8].
• Aplicação de um método de teste baseado em modelo onde o modelo representa o comportamento do atacante para explorar vulnerabilidades de SQL Injection e Cross-Site Scripting em um conjunto de serviços usados para benchmarking de robustez e segurança.
• Comparação dos resultados da técnica usada neste trabalho, com os resultados de outras a técnicas e com alguns scanners de vulnerabilidades.
1.5. Organização da dissertação
O restante deste trabalho está estruturado conforme descrito a seguir. No capítulo 2 apresentamos o referencial teórico constituído por alguns conceitos sobre ws, segurança de informação, testes baseados em modelos e testes de segurança baseados em modelo.
No capítulo 3 são apresentados os trabalhos relacionados. No capítulo 4 é apresentado o método de testes baseados em padrões de ataques que constitui a abordagem utilizada, onde cada passo do método é descrito.
No capítulo 5 aplicamos o método para testar web services e coletamos os resultados de teste de cada um dos serviços.
No capítulo 6 apresentamos a análise dos resultados e as lições aprendidas com o uso do método.
No capítulo 7 são descritas as conclusões em relação ao trabalho realizado, apresentando-se os pontos fortes, e também o que é preciso melhorar em trabalhos futuros.
2. Referencial Teórico
Este capítulo debruça-se sobre serviços web, onde primeiro apresentamos uma definição, uma descrição da Arquitetura Orientada a Serviços, a pilha de protocolos e as características dos protocolos SOAP e REST. Em seguida, há uma parte dedicada à segurança de informação e seus empecilhos, que são vulnerabilidades, ameaças, riscos e ataques; também são apresentadas técnicas de detecção de vulnerabilidades. O capítulo continua com uma parte introdutória sobre testes, a taxonomia de testes baseados em modelos e as técnicas de testes. Depois, é apresentada a classificação dos testes de segurança, bem como a taxonomia de testes de segurança baseados em modelo. Por último apresentamos alguns trabalhos que abordam testes de segurança baseados em modelo, trabalhos relacionados com testes de segurança em web services e estabelecemos uma comparação de alguns trabalhos relacionados com a nossa abordagem.
2. 1. Serviços Web
Do ponto de vista do seu funcionamento, um serviço web ou WS (do inglês web service) [9] é uma entidade de software independente de linguagem, baseada em padrões, que aceita solicitações especialmente formatadas de outras entidades de software em máquinas remotas por meio de protocolos de comunicação neutros de fornecedor e transporte, produzindo aplicativos específicos. Numa outra visão, pode ser definido como uma interface que descreve uma coleção de operações que são acessíveis pela rede por meio de mensagens XML padronizadas [3]. É um aplicativo corporativo usado na Internet e baseado em padrões e comunicações relacionados a XML. Todas as mensagens de solicitação e resposta são feitas usando HTTP (Sigla em Inglês para Protocolo de Transferência de Hipertexto) com serialização1 XML (Sigla em Inglês para Linguagem de Marcação Extensível).
2.1.1. Arquitetura Orientada a Serviços
Arquitetura Orientada a Serviços (SOA, do Inglês Service Oriented Arquitecture) é uma arquitetura conceitual que utiliza serviços para dar apoio aos negócios. O conceito de serviço é a base da SOA. Do ponto de vista de tecnologia de informação, SOA é uma abordagem que permite a criação de serviços que podem ser reutilizados entre aplicações, permitindo às organizações utilizar a sua infraestrutura de Tecnologia de Informação (TI) alinhando-o com
1A serialização é um processo de conversão de um objeto em um formulário que possa ser transportado (MSDN: https://msdn.microsoft.com/pt-br/library/182eeyhh(v=vs.120).aspx)
seus requisitos de negócio. Assim, de acordo com [10] os principais benefícios desta tecnologia de WS são:
1. A capacidade de fornecer soluções integradas e interoperáveis entre aplicativos e sistemas. WS podem interconectar-se com aplicações e sistemas, não apenas dentro da organização e da intranet, mas também na Internet.
2. Reusabilidade: um serviço pode servir muitas aplicações, diversas vezes. Por causa do seu fraco acoplamento tecnológico, serviços podem ser executados independentemente e comunicar com qualquer outro serviço.
3. Melhoria de desempenho: características dos serviços da Web, como flexibilidade, dinamismo, adaptabilidade, escalabilidade e facilidade de manutenção, permitem melhorar o desempenho nos negócios.
Uma arquitetura de web service simples possui três componentes: um provedor (ou fornecedor) de serviços, um consumidor (ou requisitante) de serviços e o registro de serviços [11]. O provedor apresenta a interface, implementação e coloca o serviço disponível na internet, enquanto que o consumidor ou cliente usa o serviço, podendo ser uma aplicação que tenta encontrar operações do serviço, assim como a localização para poder utilizá-lo. A figura 1 mostra a arquitetura de um serviço web.
2.1.2. Pilha de Protocolos de WS
A pilha de protocolos WS é constituída pelas seguintes camadas, ilustradas na Figura 2: • Camada 1: é a camada de transporte, responsável por transportar mensagens entre
as aplicações. Inclui protocolos de transporte bem conhecidos como HTTP/HTTPS, SMTP, FTP.
• Camada 2: é a camada de dados, em que as mensagens são codificadas no formato XML. O SOAP é o protocolo de mensagens XML.
• Camada 3: é a camada de descrição dos serviços, responsável por descrever a interface pública para um serviço web específico. A descrição desta interface se dá principalmente pelo uso de WSDL (Web Services Description Language) mas também pode ser através da política.
• Camada 4: é a camada de descoberta de serviços, i.e., fornece serviços de “publicar” e “localizar” por meio de um registro centralizado.
2.1.4. SOAP
O SOAP é um protocolo de mensagens, unidirecional e sem estados (stateless) baseado em XML, de padrão aberto, que forma um arcabouço para a comunicação entre objetos e serviços Web. Foi projetado para ser um protocolo para o ambiente distribuído e descentralizado, que utiliza o poder da Internet e do XML para transmitir informações digitadas entre diferentes nós [12]. Um cliente envia uma mensagem SOAP para o servidor. A resposta do servidor volta junto com o serviço solicitado. Os protocolos da Web estão instalados e disponíveis para as principais plataformas de sistema operacional. O SOAP especifica exatamente como codificar um cabeçalho HTTP e um arquivo XML para que um programa em um computador possa chamar um programa em outro computador e passar informações.
Mensagem SOAP
Uma mensagem SOAP (a figura 3 ilustra a sua estrutura) é codificada como um documento XML, consistindo em um elemento <Envelope>, que contém um elemento <Header> opcional e um elemento <body> obrigatório. O elemento <Fault>, contido no <Body>, é usado para relatar erros. Estes componentes da mensagem SOAP são descritos a seguir.
Figura 3: Estrutura de uma mensagem SOAP O Envelope SOAP
<Envelope> é o elemento-raiz em cada mensagem SOAP e contém dois elementos filhos, um elemento <Header> que é opcional e um elemento <Body> que é obrigatório.
<Header> é um subelemento opcional do envelope SOAP e é usado para transmitir informações relacionadas ao aplicativo que deve ser processado por nós SOAP associados ao caminho da mensagem.
O Corpo do SOAP
<Body> é um subelemento obrigatório do envelope SOAP, que contém informações para o destinatário final da mensagem.
Na figura 4, ilustramos uma mensagem SOAP acompanhada da respectiva resposta.
Figura 4 : Requisição (Mensagem) SOAP e Resposta
O elemento Fault
<Fault> é um subelemento do corpo SOAP, que é usado para relatar erros. A tabela 1 descreve os sublementos de <fault>.
Tabela 1:Subelementos de Fault
Nome do Elemento Descrição
faultcode O elemento <faultcode> é um elemento obrigatório no elemento <Fault>. Ele fornece informações sobre a falha em um formulário que pode ser processado pelo software. SOAP define um pequeno conjunto de códigos identificando falhas SOAP básicas e esse conjunto pode ser estendido por aplicativos.
faultstring O subelemento <faultstring> é um elemento obrigatório no elemento <Fault>. Fornece informações sobre a falha em um formulário destinado a um leitor humano.
faultactor O elemento <faultactor> contém o URI do nó SOAP que gera a falha. Um nó SOAP que não seja o receptor SOAP final deve incluir o elemento <faultactor> quando cria uma falha; um receptor SOAP final não é obrigado a incluir este elemento, mas pode fazê-lo.
detail O elemento <detail> transporta informações de erro específicas do aplicativo relacionadas ao elemento <Body>. Ele deve estar presente se o conteúdo do elemento <Body> não tiver sido processado com êxito.
2.1.5. Representational State Transfer (REST)
O Representational State Transfer (REST) é um estilo de arquitetural para projetar WS fracamente acoplados.
O estilo é baseado na comunicação utilizando HTTP. Diferentemente do SOAP, o modelo REST utiliza os métodos do HTTP (Get, Post, Put e Delete), utilizando uma estrutura de mensagens mais simples e sem necessidade da criação de camadas intermediárias como no SOAP, mostradas em 2.1.4. Os WS que utilizam o estilo REST (chamados de serviços RESTful) usam os métodos HTTP para publicar dados (criar/atualizar), ler dados (fazer consultas) e excluir dados. Portanto, o REST usa HTTP da seguinte forma:
• POST para criar um recurso no servidor; • GET para recuperar um recurso;
• DELETE para remover ou excluir um recurso.
O uso do estilo REST é mais flexível quando comparado com SOAP. Além da simplicidade da estrutura, citada anteriormente, temos ainda: i) enquanto SOAP apenas suporta XML para mensagens, REST suporta vários formatos; ii) outras vantagens de REST é que ele consome menos largura de banda do que SOAP, e requer menor acoplamento entre cliente e servidor [13].
2.2. Segurança de Informação
Nesta seção abordamos aspectos sobre segurança de informação (security). Focamos nas propriedades de segurança, que é o que se deve ter em conta quando se pensa em garantir segurança de informação num sistema. Como o nosso objetivo é estudar testes de penetração, falamos dos entraves à segurança, isto é, o que pode levar à perda de segurança. Em seguida apresentamos algumas vulnerabilidades comuns a serviços web e descrevemos SQLI e XSS que serão o enfoque dos nossos testes, posteriormente e, finalmente, apresentamos as técnicas de detecção de vulnerabilidades.
2.2.1. Conceitos de Segurança de informação
É importante resguardar a informação e os sistemas que a administram. A segurança da informação (Security) é a proteção da informação contra diversos tipos de ataques, quer intencionais, quer acidentais. As propriedades da segurança de informação são: a confidencialidade, a integridade e a disponibilidade. Em [14] estas propriedades são tratadas como requisitos de segurança de informação e são definidas da seguinte forma:
a) Confidencialidade (Confidentiality): Preservação das restrições autorizadas no acesso à informação e divulgação, incluindo os meios para proteger a privacidade pessoal e informações proprietárias. A perda de confidencialidade é a divulgação não autorizada de informações.
b) Integridade (Integrity): Proteção contra modificação imprópria ou destruição de informação, incluindo a garantia de não-repúdio da informação e autenticidade. Não repúdio visa garantir que o autor não negue ter criado e assinado o documento. A perda de integridade é a modificação não autorizada ou destruição da informação. c) Disponibilidade (Availability): Garantia do acesso em tempo útil e confiável de
informações e seu uso. A perda de disponibilidade é o rompimento de acesso ou uso de informações ou um sistema de informação.
Ainda de acordo com [14] para além da tríade confidencialidade, integridade e disponibilidade (CIA, do Inglês Confidentiality, Integrity and Availability) há ainda dois conceitos muito utilizados no contexto de segurança de informação em computadores, nomeadamente:
d) Autenticidade (Authenticity): A propriedade de que a fonte da informação é genuína e confiável, podendo ser verificada; confiança na validade de uma transmissão, uma mensagem ou a origem de uma mensagem. Isto significa verificar se os usuários são
quem dizem que são e que cada entrada que chega ao sistema veio de uma fonte confiável.
e) Responsabilização (Accountability): A meta de segurança que gera o requisito que permite que ações de uma entidade possam ser rastreadas exclusivamente para essa entidade. Esta propriedade suporta não-repúdio, dissuasão, isolamento de falhas, detecção e prevenção de intrusão, recuperação pós-ação e ação judicial. Não-Repudio fornece proteção contra a negação por uma das entidades envolvidas em uma comunicação de ter participado de toda ou parte da comunicação. Como os sistemas verdadeiramente seguros ainda não são uma meta alcançável, temos de ser capazes de rastrear uma violação de segurança para uma parte responsável. Os sistemas devem manter registos das suas atividades para permitir a análise forense depois de rastrear violações de segurança ou para ajudar em disputas de transação. 2.2.2. Entraves à Segurança da Informação
Nesta seção apresentamos alguns conceitos que constituem entraves de segurança de um sistema de informações baseadas em [15], [14] e [16], e que serão importante para este trabalho.
Uma ameaça é qualquer perigo potencial associado à exploração de uma vulnerabilidade. A ameaça é a circunstância em que alguém pode identificar uma vulnerabilidade específica e a use contra a empresa ou o indivíduo. A entidade que aproveita uma vulnerabilidade é referida como um agente de ameaça. Um agente de ameaça pode ser um intruso acessando a rede através de uma porta no firewall, um processo acessando dados de uma forma que viole a política de segurança, um desastre natural a aniquilar uma instalação ou um funcionário a cometer um erro não intencional que possa expor informações confidenciais [16].
Ataque é qualquer ação que comprometa a segurança das informações pertencentes a uma organização. Um ataque é, de acordo com [5] um fator externo que depende principalmente da intencionalidade e capacidade dos seres humanos para invadir maliciosamente o sistema, aproveitando as vantagens das vulnerabilidades. Um ataque pode resultar em danos para um sistema ou entidade [15]. Neste trabalho consideramos ainda que é uma técnica específica usada para explorar uma vulnerabilidade, tentando destruir, expor, alterar, inutilizar, roubar ou ganhar acesso não autorizado ou fazer uso não autorizado de dados. Um ataque é a realização concreta de uma ameaça.
Vulnerabilidades de segurança são falhas específicas no código da aplicação as quais criam “brechas” na segurança permitindo que pessoas mal-intencionadas modifiquem, destruam ou roubem informações ou, de acordo com [16] é a falta de uma contramedida ou uma fraqueza em uma contramedida que está em vigor. Pode ser uma fraqueza de software, hardware, procedimentos ou uma fraqueza humana que pode ser explorada. Uma vulnerabilidade pode ser um serviço executado em um servidor, aplicativos ou sistemas operacionais não corrigidos, um ponto de acesso sem fio irrestrito, uma porta aberta em um firewall, segurança física negligente que permite a qualquer pessoa entrar em uma sala de servidores ou gerenciamento de senha não forçado em servidores e estações de trabalho. Tal como referem em [17] ataques são explorações bem-sucedidas de vulnerabilidades.
Em [17] apresentam abordagens para atenuar a ocorrência de cinco vulnerabilidades que se podem ser encontradas nas aplicações.
2.2.3. Vulnerabilidades mais comuns em Serviços Web
A maioria dos web services comunicam através do protocolo HTTP, conforme foi visto em 2.1.4 e 2.1.5, e por isso sofrem dos mesmos problemas que aplicações web comuns. Existem inúmeras vulnerabilidades em serviços web. Algumas delas são apresentadas em [1] no seu trabalho sobre segurança de serviços web. O sítio (website) [18], elabora periodicamente uma lista de vulnerabilidades encontradas geralmente em aplicações web. Essa mesma lista se aplica também a serviços web. Porém o objetivo deste trabalho não é discutir todas as vulnerabilidades e, portanto, abordaremos no capítulo 7 duas dessas vulnerabilidades que constam do [18]: SQL Injection (SQLI) e Cross Site Scripting (XSS). SQLI permite ao atacante comprometer o banco de dados do sistema, podendo expor dados, modificar ou eliminar dados importantes do sistema, bem como apagar todo o banco de dados da aplicação. XSS, por outro lado permite roubar cookies, levando atacante a obter controle de navegador do usuário a fim de executar um script malicioso dentro do contexto de confiança do sitio (web site) do aplicativo web [19]. Na seção 2.2.3.1 descrevemos em detalhe o SQLI e XSS é descrito em 2.2.3.1.
2.2.3.1. SQL Injection (SQLI)
Esta vulnerabilidade é revelada quando se dá a um invasor (ou atacante) a capacidade de modificar as consultas SQL (Structured Query Language) que um aplicativo transmite para um banco de dados [20]. Ela ocorre quando o desenvolvedor não garante que os valores recebidos de um formulário, cookie, parâmetro de entrada e assim por diante, sejam
validados ou codificados antes de serem passados para consultas SQL que serão executadas em um servidor de banco de dados.
Por exemplo, um aplicativo simples que leva registros de um nome de usuário e senha. O aplicativo pode processar este registro em uma instrução SQL como esta:
string query = "SELECT * FROM usuário WHERE id_usuario = “admin” AND senha= “senha”;.
Uma vez que esta consulta é construída pela concatenação de uma cadeia de entrada fornecida diretamente pelo usuário, a consulta funciona corretamente somente se a senha não contém um caractere de apóstrofo. Se o usuário digita:
“Maria” como o nome de usuário e por exemplo ‘or’ a '=' a como a senha, a consulta resultante torna-se:
string query = "SELECT * FROM usuário WHERE id-usuário = “‘or’ a’ = ‘a”AND senha= “‘or’ a’ = ‘a ”.
O String ‘or’ a’ = ‘a pode provocar um problema no banco de dados. Pode revelar dados sensíveis, por exemplo: todos nomes de usuários e senhas. Na figura 5, temos um caso de SQLI aplicado a um serviço web e que desencadeia uma situação de dados sensíveis serem revelados.
Os passos para realizar SQLI são os seguintes [20]:
1. Localizar pontos de entrada de dados, por exemplo, um formulário. 2. Enviar código SQL malicioso para o banco de dados.
3. Se esse ataque for possível para o sistema, ações prejudiciais poderão ser executadas no banco de dados.
Todo e qualquer campo de um site é como um ponto de entrada para o banco de dados. Qualquer dado ou entrada que inserimos em qualquer campo do sistema ou site vai para a consulta do banco de dados. Portanto, em vez de dados corretos, se digitar algum código malicioso, ele poderá ser executado na consulta do banco de dados e trazer consequências prejudiciais.
As consequências de um ataque de SQLI podem ser as seguintes [20]: • Comprometimento da conta de um usuário;
• Roubo e cópia de dados confidenciais do site ou do sistema; • Alteração os dados confidenciais do sistema;
• Exclusão dados confidenciais do sistema; • Autenticação com conta de outro usuário. • Divulgação de informações privadas a usuários; • Modificação da estrutura do banco de dados; • Controlo ilegítimo do servidor de banco de dados.
A seguir descrevemos algumas variedades de SQLI de acordo com [21] de modo explicar diferentes formas de realizar este tipo de ataque:
a) Tautologias
Ataque baseado em tautologia consiste em injetar código em uma ou mais instruções condicionais para que elas sejam sempre avaliadas como verdade. O exemplo dado na figura 5 ilustra uma tautologia. Os ataques mais comuns utilizando esta técnica visam ignorar páginas de autenticação e extrair dados.
Se o ataque for bem-sucedido a aplicação pode retornar todos os registros da tabela de um banco de dados ou pelo menos, um registro. Ou seja, o valor esperado de uma consulta atacada é o retorno de dados.
b) Consultas logicamente incorretas
Esse ataque permite a coleta de informações importantes sobre o tipo e a estrutura do banco de dados de um aplicativo Web. Esta técnica costuma ser empregada como uma etapa
preliminar de coleta de informações para outros ataques [20]. Ao executar esse ataque, um invasor tenta inserir instruções que causam uma sintaxe, conversão de tipo ou erro lógico no banco de dados. Em caso de sucesso a página de erro retornada pelos servidores de aplicativos é muitas vezes excessivamente descritiva. Uma mensagem de erro gerada pode revelar parâmetros vulneráveis/injetáveis para um atacante. Informações de erro adicionais, originalmente destinadas a ajudar os programadores a depurar seus aplicativos, ajudam ainda mais atacantes a obter informações sobre o esquema do banco de dados.
Exemplo: Tentativa de causar um erro de conversão de tipo2. Para fazer isso, o invasor insere
o seguinte texto no campo de entrada: “convert (int, (selecione o primeiro nome de sysobjects onde xtype = 'u'))”. A consulta resultante é:
SELECT contas FROM usuario WHERE id_usuário= “AND pass=“AND pin= convert(int,(select top 1 name fromsysobjects where xtype=’u’))
A consulta (query) tenta extrair a primeira tabela de usuários (xtype = 'u') da tabela de metadados do banco de dados. Em seguida, tenta converter este nome de tabela em um inteiro. Como essa não é uma conversão de tipo legal, o banco de dados lança um erro. Para o Microsoft SQL Server, o erro seria:
“Microsoft OLE DB Provider for SQL Server (0x80040E07) Error converting nvarchar value ’CreditCards’to a column of data type int.”
Neste exemplo de mensagem de erro lançado pelo banco de dados, o atacante pode se beneficiar de duas informações. Primeiro ele fica a saber que o servidor do banco de dados é SQL Server database. Segundo a mensagem de erro revela o valor da sequência de caracteres que causou a ocorrência da conversão de tipo. Por coincidência, este valor é também o nome do delimitador da consulta (;) e executa a segunda consulta injetada que poderia resultar na eliminação da tabela users, provavelmente destruindo informação valiosa.
c) Union-query
Nesta variante de SQLI, o atacante explora um parâmetro vulnerável para alterar o conjunto de dados retornado por uma determinada consulta. Com essa técnica, um atacante pode levar o aplicativo a retornar dados de uma tabela diferente da que foi destinada pelo
desenvolvedor. Os atacantes injetam uma instrução do tipo: UNION SELECT <alguma coisa> em um formulário.
O resultado esperado deste ataque é que o banco de dados retorne um conjunto de dados (dataset) que é a união dos resultados da primeira consulta (consulta original) e resultados da segunda consulta (consulta injetada).
Exemplo: Um atacante poderia inserir o texto no campo de login:
“UNION SELECT cardNo from CreditCards onde acctNo = 10032 - -” Isso poderia resultar na seguinte consulta:
SELECT accounts FROM users WHERE login=’’ UNION SELECT cardNo from CreditCards where acctNo=10032 -- AND pass=’’ AND pin=
Supondo que não haja login igual a “”, a primeira consulta retorna o conjunto nulo, enquanto a segunda consulta retorna dados da tabela “CreditCards”. Nesse caso, o banco de dados retornaria a coluna “cardNo” para a conta “10032”. O banco de dados obtém os resultados dessas duas consultas, unifica-os e os retorna para o aplicativo.
Em muitas aplicações, o efeito dessa operação é que o valor de “cardNo” é exibido junto com as informações da conta.
d) Procedimentos armazenados (Stored Procedures)
Um procedimento armazenado é um conjunto de instruções SQL com um nome atribuído armazenado em um banco de dados [20]. SQLI deste tipo tenta executar procedimentos armazenados presentes no banco de dados. Atualmente, a maioria dos bancos de dados possui um conjunto padrão de procedimentos armazenados que ampliam a funcionalidade do banco de dados e permitem a interação com o sistema operacional. Portanto, uma vez que um atacante determina qual banco de dados está em uso o SQLI pode ser criado para executar procedimentos armazenados fornecidos por esse banco de dados específico. O código 1 representa um exemplo de procedimento armazenado.
Neste exemplo, o procedimento armazenado retorna um valor verdadeiro/falso para indicar se as credenciais do usuário foram autenticadas corretamente. Ao usar a técnica de SQLI, o atacante simplesmente injeta “’; SHUTDOWN (desligar); - -” nos campos userName ou password. Essa injeção faz com que o procedimento armazenado gere a seguinte consulta: SELECT accounts FROM users WHERE login=’doe’ AND pass=’’; SHUTDOWN; -- AND pin=
A primeira consulta é executada normalmente e, em seguida, a segunda consulta mal-intencionada é executada, o que resulta em um encerramento do banco de dados.
2.2.3.2. Cross site scripting
Cross-Site Scripting (XSS) é uma vulnerabilidade encontrada normalmente em aplicações web que permite ao atacante inserir código em uma página visitada por outro usuário [22], [23], [24]. O XSS geralmente representa uma falha crítica de segurança e pode resultar na perda de privacidade de clientes de um determinado site ou aplicativo. Um ataque de XSS pode ser combinado com outras vulnerabilidades para efeito devastador. Em algumas situações, um ataque XSS pode ser transformado em um vírus ou worm3 [25] auto propagável. Um usuário vitima de XSS pode ter sua conta invadida (roubo de cookie) e seu navegador é redirecionado para outro local da página [19]. A figura 7 ilustra a inserção de um código malicioso numa requisição (request) SOAP.
Um site é vulnerável a XSS se forem respeitadas determinadas condições. Primeiro o site tem de aceitar e, posteriormente, retornar a mesma entrada de volta para um usuário.
As vulnerabilidades do XSS vêm em várias formas e podem ser divididas em três variedades [23]: o refletido, o armazenado e baseado em Document Object Model Based (DOM-Based).
3Worm é um termo em Inglês que significa verme. É um código malicioso que se propaga pela rede com ou sem assistência humana [25]
O XSS refletido é o mais comum, sendo o principal responsável por ataques de phishing. Phishing é uma técnica de enganar usuários de sistemas informáticos, levando-os a revelar informações pessoais [26]. Pode realizar-se enviando e-mails falsos ou redirecionando o usuário para websites falsos. A seguir apresentamos em detalhe as variedades de XSS:
a) XSS refletido
O XSS refletido, de acordo com Stuttard e Pinto [23], funciona da seguinte seguindo o seguinte roteiro que é ilustrado através da figura 8:
1. O usuário autentica-se numa aplicação e emitido um cookie contendo um token 2. O atacante ilude o usuário para através do seguinte link que contém código
malicioso em JavaScript;
3. O usuário pede acesso ao URL malicioso fornecido à aplicação pelo atacante, confiando tratar-se de um correspondente a um site normal.
4. O servidor responde ao pedido do usuário e, como resultado do XSS a resposta contém o JavaScript que o atacante criou.
5. O JavaScript malicioso que o atacante criou é var i=new Image; i.src=” http://mdattacker.net/” +document.cookie;
6. Este código faz com que o usuário faça um pedido para mdattacker.net que é um domínio pertencente ao atacante.
O pedido contém o token da sessão corrente do usuário na aplicação:
GET /sessId=184a9138ed37374201a4c9672362f12459c2a652491a3 HTTP/1.1 Host:
mdattacker.net
7. O atacante monitora pedidos do mdattacker.net e recebe o pedido do atacante. Usa o token do usuário para se controlar a sessão do usuário, ganhando acesso as informações do usuário e realizar ações do seu interesse.
Figura 7: Funcionamento do XSS Refletido [23].
b) XSS armazenado
Um usuário registrado é normalmente rastreado usando um cookie de ID de sessão autorizando a publicação de conteúdo. Se um atacante postasse uma mensagem contendo um JavaScript especialmente criado, um usuário que estivesse lendo a mensagem poderia ter seus cookies e sua conta comprometidos. É considerado o tipo mais perigoso, pois não depende da ação do usuário e frequentemente acontece em sites no qual o atacante pode postar texto, como, por exemplo, fóruns, Orkut, Twitter, Facebook, etc. Para realizar este tipo de ataque, a sequência de passos é a que é ilustradada na figura 9 de acordo com Stuttard e Pinto [23]:
Figura 8:Funcionamento de XSS armazenado [23].
c) XSS baseado no DOM4
É a exploração de uma vulnerabilidade de validação de entrada causada pelo cliente, não pelo servidor. Portanto, o XSS baseado em DOM não é resultado de uma vulnerabilidade dentro de um script do lado do servidor, mas de um tratamento inadequado dos dados fornecidos pelo usuário no JavaScript do lado do cliente. Como os outros tipos de vulnerabilidades XSS, o XSS baseado em DOM pode ser usado para capturar informações confidenciais ou sequestrar a conta do usuário. No entanto, é essencial entender que esse tipo de vulnerabilidade depende exclusivamente do JavaScript e do uso inseguro de dados obtidos dinamicamente a partir da estrutura DOM. A figura 10, mostra um exemplo deste tipo de ataque. De acordo com Stuttard e Pinto [23], este tipo de ataque pode ser realizado obedecendo o seguinte processo:
• O usuário pede acesso ao URL preparado pelo atacante que contém um JavaScript malicioso;
• O servidor não contém nenhum JavaScrip malicioso.
• Quando o navegador do usuário processa a resposta; mesmo assim é executado
Código 2: Exemplo de DOM based
Observando o código da figura 11 conclui-se que o desenvolvedor esqueceu de limpar o valor do parâmetro "name" get, que é posteriormente escrito dentro do documento assim que é recuperado.
Figura 9: Funcionamento do DOM-based XSS [23].
2.2.4. Técnicas de Detecção de Vulnerabilidades
Antunes e Vieira [2] apresentam uma lista de métodos e ferramentas de testes de detecção de SQLI em ws. Neste trabalho, os autores primeiramente dividem as técnicas em duas
grandes categorias: técnicas de caixa branca e técnicas de caixa-preta; depois apresentam algumas ferramentas e descrevem como elas funcionam.
As técnicas de caixa branca focam no código, e tanto podem ser realizadas manualmente quanto automaticamente. Um exemplo de técnica manual é a inspeção de código, onde o programador entrega o código para ser revisado por seus pares. É uma técnica bastante efetiva, mas que pode levar muito tempo para encontrar todas as vulnerabilidades; também é muito cara porque requer profissionais treinados para realizar a inspeção. Uma outra técnica manual é a revisão de código fonte, que não é tão cara quanto a inspeção e pode ser considerada quando o código alvo é pouco crítico. Um exemplo de técnica automática de detecção de vulnerabilidade é a análise estática de código. Ferramentas para este fim analisam o software, na forma de código-fonte ou binário, na tentativa de identificar defeitos comuns de implementação. A efetividade dessas ferramentas varia dependendo de sua sofisticação: podem considerar apenas declarações, ou dependências entre linhas de código, entre outros. O grande problema dessas ferramentas é que podem gerar muitos falsos positivos. Dentre as ferramentas de análise de código destacamos FindBugs [27]5, IntelliJ IDEA [28]6, pixy [29].
Neste trabalho utilizaremos uma técnica de testes caixa preta. Antes, introduzimos alguns conceitos gerais sobre testes, depois, sobre aspectos de testes de segurança e por fim, sobre testes baseados em modelos e sua aplicação aos testes de segurança, que são o objetivo deste trabalho.
2.3. Testes
Neste trabalho consideramos que testes consistem em executar um sistema ou componente com o intuito de detectar diferenças entre o comportamento obtido e o esperado [30]. Para isso é necessário submeter o sistema em testes (SET) a um conjunto finito de casos de teste, devidamente selecionados a partir de um domínio de entradas possíveis que é potencialmente infinito. A seleção é feita com o uso de critérios [31] que são condições que um conjunto de testes deve satisfazer, geralmente em termos de elementos do SET que devem ser exercitados durante os testes. Uma vez executados os casos de teste, deve-se determinar um veredicto, que pode ser passou (o comportamento observado é conforme ao esperado), falhou (o comportamento do SET não é conforme o esperado) ou inconclusivo (não dá para identificar
5http://findbugs. sourceforge.net/ 6https://www.jetbrains.com/idea/
sucesso ou falha). O veredicto é fornecido por um mecanismo designado como oráculo de teste. Para compreender melhor sobre testes baseados em modelos, apresentamos na tabela 2, conceitos de testes de acordo com a definição de Weissleder (2009):
Tabela 2: Conceitos Sobre Testes
Conceito Definição
Software em Teste Software em Teste (SET) é o Software que está a ser submetido a avaliação com o fim de encontrar erros.
Casos de Teste Um caso de teste é uma sequência de estímulos de entrada fornecidos a um sistema bem como a saída esperada do sistema. Um caso de teste pode existir em muitos níveis diferentes de abstração. A distinção mais importante é entre os casos abstratos e concretos de teste.
Caso de Teste Abstrato Um caso de teste abstrato consiste em informação abstrata sobre
a sequência de entrada e saída. Casos de teste abstratos são independentes de plataforma de execução e são muitas vezes o primeiro passo na criação de casos de teste. São usados para se ter uma ideia da estrutura de caso de teste/obter informações sobre critérios de cobertura satisfeitos.
Casos de Teste
Concretos
Casos de teste concreto compreendem a informação completa de teste e pode ser executado no SET. Casos de teste concretos são dependentes de plataforma.
Oráculo Um oráculo é um artefato que compreende o conhecimento
sobre o comportamento esperado da Software em Teste. É utilizado na análise dos resultados, para determinar se as saídas produzidas são iguais as esperadas.
Software de Teste Software de Teste é qualquer tipo de software que pode ser usado no processo de teste. Representantes comuns são geradores de teste, estruturas de teste, bem como conjuntos de teste.
Framework de Teste É uma infraestrutura com o objetivo de automatizar o processo de teste, executar conjuntos de testes, e gerar o relatório correspondente.
2.3.1. Técnicas de Teste
O teste pode ser realizado sob várias condições. Dois dos aspectos mais influentes são o conhecimento e possibilidade de observação da estrutura interna do SET. A seguir, apresentamos as definições de teste de caixa-preta, teste de caixa branca e testes de caixa cinza, segundo [32]:
a) Teste de Caixa Preta
O teste de caixa preta é baseado na análise das especificações de um software sem referência ao seu funcionamento interno. Em testes de caixa-preta, a estrutura interna do SET não é considerada pelo testador. O testador só tem conhecimento sobre possíveis valores de entrada e de saída. O SET é visto como uma caixa-preta (figura 10). Dado que o teste de caixa-preta só permite testar a funcionalidade por meio de entrada-saída, muitas vezes é chamado de teste funcional.
Figura 10: Exemplo de Caixa Preta
Um exemplo de teste de caixa preta é quando recorremos ao ZAP para avaliar uma determinada aplicação quanto a presença ou não de vulnerabilidades. No exemplo da figura 13 é possível observar que o teste é realizado sem que o testador tenha acesso à estrutura interna da aplicação, neste caso o Moodle.
Figura 11: Exemplo de um teste usando ZAP (teste de caixa preta) b) Teste de Caixa Branca
O teste de caixa branca é o processo de fornecer a entrada para o sistema e verificar como o sistema processa essa entrada para gerar a saída necessária. É necessário que um testador tenha acesso ao código fonte. O teste de caixa branca é aplicável principalmente nos níveis de unidade e de integração, no processo de teste de software. No teste de caixa-branca a estrutura interna do SET é conhecida, bem como o código fonte e, consequentemente, o testador pode utilizar este conhecimento para criar os testes.
Figura 12: Exemplo de Análise de Código com FindBugs c) Teste Caixa Cinza
Teste caixa-cinza é uma abordagem de combina as vantagens de teste de caixa branca e teste de caixa-preta. Esta técnica de teste é usada para projetar testes em nível de caixa-branca e executá-los no nível de caixa-preta.
2.3.2. Testes Baseados em Modelo
Teste baseado em modelo ou MBT (do inglês, Model Based Testing) [33], [34] é uma abordagem para automatizar o processo de teste. Constitui uma técnica de testes caixa-preta em que os critérios são definidos em termos de um modelo que representa o comportamento do SET e/ou de seu ambiente segundo Utting, Prestner e Leagard [35]. Geralmente baseia-se nas especificações do SET cobertas pelo modelo e baseia-seu sucesso depende da qualidade do modelo já que idealmente o comportamento do sistema será equivalente ao do modelo. Teste baseado em modelo envolve as seguintes atividades principais: i) a construção do modelo que é realizado a partir dos requisitos ou de uma especificação que posteriormente se designa
modelo de teste e se destina a responder os objetivos do teste, ii) geração dos casos de teste guiada pelos critérios de seleção. Esses critérios podem se basear nas funcionalidades do sistema ou elementos do modelo, por exemplo, cobertura de todas as funcionalidades, ou cobertura de todas as transições do modelo de estados, iii) transformação de critérios de seleção de teste em especificações de caso de teste. Se necessário, dado que, em geral, os casos de testes gerados estão no mesmo nível de abstração do modelo de testes para que sejam executados automaticamente é necessário descrevê-los em formato compatível com a plataforma na qual serão executados, iv) execução dos casos de testes, em que as entradas de teste são fornecidas ao SET (controle) e saídas produzidas são recolhidas (observação). A execução pode ocorrer de forma articulada com a geração dos casos de teste, o que é designado como testes em linha (online), v) análise de resultados, em que as saídas observadas são comparadas com as saídas esperadas e um veredicto é emitido: passou (v), falhou (x) ou inconclusivo (?).
A breve descrição acima foi baseada na taxonomia proposta por [35], que está resumida na Figura 13.
2.4. Testes de segurança
Testes de segurança validam os requisitos do sistema de software relacionados com propriedades de segurança tais como a confidencialidade, integridade, disponibilidade, autenticação, autorização e não-repúdio [14]. Têm como objetivo encontrar vulnerabilidades não descobertas durante o desenvolvimento que podem ser exploradas.
Nesta seção debruçamo-nos sobre alguns aspectos de testes de segurança. Inicialmente falamos sobre duas perspectivas de classificação de testes de segurança na seção 2.4.1, nomeadamente: testes funcionais de segurança e testes de vulnerabilidades de segurança. Em seguida apresentamos na seção 2.4.2 a Taxonomia de Felderer sobre testes de segurança baseados em modelo, que é uma extensão da Taxonomia de Testes baseados em Modelos proposta por Utting et al [35] que vimos na Seção 2.3.
2.4.1. Classificação dos Testes de Segurança
De acordo com Quian, et al, [36], testes de segurança estão relacionados com a verificação dos serviços de segurança de aplicativos e possível identificação dos defeitos de segurança em potencial.
Duas principais abordagens de teste de segurança podem ser distinguidas, nomeadamente, testes de vulnerabilidade de segurança e testes funcionais de segurança de acordo com [37]. Testes funcionais de segurança validam se os requisitos de segurança especificados estão corretamente executados. Já os testes de vulnerabilidades de segurança buscam revelar vulnerabilidades do sistema que correspondem a defeitos introduzidos de forma não intencional. Um exemplo desde tipo de testes são os testes de penetração. Eles requerem que o testador pense como um atacante, o que requer uma capacitação diferente daquela necessária para testar funcionalidades, e por isso são mais difíceis de automatizar. Uma análise de risco é necessária para identificar as partes do SET em que ataques têm mais chances de serem bem-sucedidos. Por se tratar de uma técnica de caixa preta, é muito utilizada para testar serviços Web. Uma das técnicas mais utilizada é o fuzzing sobre as solicitações HTTP da Web. Fuzzing é uma técnica de testes automatizada ou semi-automatizada que envolve o fornecimento de dados aleatórios ao SET. Em suma, o teste de fuzz, ou “fuzzing”, descreve o processo de geração e envio automático de entrada malformada para o software em teste, enquanto monitora seu comportamento para anomalias [38]. Neste trabalho não utilizaremos fuzzing, que se baseia unicamente na interface, mas testes baseados em modelos, apresentada a seguir.
2.4.2. Testes de Segurança Baseados em Modelo
No contexto específico de testes de segurança baseados em modelos ou MBST (do Inglês, Model Based Security Testing), baseamo-nos na taxonomia introduzida por [8]. Esta, por sua vez, estende a taxonomia introduzida por [34] para MBT, descrita na seção 2.3, para melhor refletir aspectos de testes de segurança. Neste sentido foram introduzidos dois grupos de critérios: filtragem (ou seleção) e evidência como se pode observar na figura 14.
Figura 14: Taxonomia de MBST. Fonte: [8]
2.4.2.1. Critérios de Filtragem
Os critérios de filtragem compreendem aspectos da modelagem da segurança, assim como critérios de seleção dos casos de teste, conforme descrevemos a seguir:
a) Modelo de segurança do sistema – são modelos parciais de um SET que se concentram em aspectos de segurança. Estes modelos podem representar propriedades de segurança (ex.: expressão lógica que caracterize a confidencialidade ou autenticidade do sistema), ou vulnerabilidades (ex.: operações para mudar parâmetros de interface para simular ataques) e funcionalidade dos mecanismos de segurança (ex.: modelagem dos mecanismos de controle de acesso).
b) Modelo de segurança do ambiente – são modelos de aspectos do contexto técnico, organizacional e operacional de segurança de um SET. Eles se concentram nas potenciais causas e consequências do comportamento do sistema e interfaces para o
SUT. Exemplo típico são os modelos de ataque, que representam sequências de ações realizadas por um atacante para explorar vulnerabilidades. Este tipo de modelo foi usado neste trabalho e é apresentado no capítulo 3.
c) Critérios explícitos de seleção de teste – são os critérios de cobertura utilizados para a seleção de casos de teste e são baseados nos critérios de seleção de testes de Utting et al. [33], que podem ser vistos na Figura 13.
Um outro ponto importante nesta taxonomia diz respeito às formas de demonstrar evidências de que o método proposto é útil. Estes pontos serão abordados na seção 2.4.2.2.
2.4.2.2. Critérios de Evidência
Critérios de evidência, por outro lado, avaliam a aplicabilidade e utilidade na prática de abordagens MBST, bem como o estado real do sistema em pesquisa. Os critérios de evidência são os seguintes:
a) Maturidade do sistema avaliado – captura a solidez técnica e grau de implantação do sistema mais maduro usado para avaliar uma abordagem MBST. Pode-se ter desde um protótipo até um sistema em operação.
b) Medidas de Evidência: determinam os critérios qualitativos de avaliação ou quantitativos para avaliar uma abordagem MBST em um aplicativo específico.
c) Nível de evidência: determina se a abordagem é avaliada no nível de casos de testes abstratos ou concretos. É abstrato se é avaliado com base em casos de teste não executáveis. Nestes casos eficiência pode, por exemplo, ser medida com base em um modelo de custo ou tempo. Mas, o efeito concreto da abordagem no SET não pode ser medido. O nível é considerado concreto se a avaliação é feita com base nos casos de teste executáveis em relação ao SET.
3. Revisão trabalhos relacionados
As abordagens de testes baseados em modelo têm chamado a atenção nos últimos anos. Esses métodos usam modelos do SET para derivar casos de teste a partir deles. Os casos de teste depois, são executados contra o programa e a saída é comparada com os valores esperados, para descobrir se o programa se comporta de acordo com sua especificação representada pelo modelo. Na seção 3.1 apresentamos alguns trabalhos que abordam testes de segurança baseados em modelo, em 3.2 apresentamos trabalhos relacionados com testes de segurança em web services e em 3.3 fazemos uma comparação entre os trabalhos relacionados a MBT e a nossa abordagem
3.1. Testes de segurança baseados em modelos
Existem inúmeros trabalhos na área de testes de segurança baseados em modelos; aqui, apresentamos alguns, que são mais parecidos com a proposta utilizada. Um destes trabalhos envolve a criação de três modelos [39]: um de especificação padrão que é abstrato e é designado como sistema de transição de estados; um modelo de implementação que aplica o conceito de injeção de falhas e representa uma mutação a ser aplicada no modelo de estados. O terceiro modelo representa a intenção do atacante e funciona como objetivo de teste. Este modelo é usado para gerar dados adequados que são depois combinados com o modelo baseado em falhas ligando o modelo de especificação e o modelo de implementação. Casos de teste podem ser gerados com recurso constraint solvers7 e consiste na identificação de contextos de falhas8.
Um outro trabalho utiliza grafos acíclicos dirigidos (DAG-Directed Aciclic Graphs) como modelo de ataques para avaliação de segurança [40]. Este modelo representa o comportamento do atacante. É usado um parser das políticas do firewall que converte as suas regras9 para o DAG e, em seguida, cada sequência de regras no DAG é considerada como uma sequência de eventos. Na etapa de geração de casos de teste, um algoritmo cria um caso de teste para cada sequência completa de eventos, que são derivadas do DAG. A geração de teste para este método usa critérios de cobertura de transições e de cobertura de estados;
7Este conceito vem de Programação por Restrições que é o “estudo de sistemas computacionais baseados em restrições” onde uma restrição é uma relação lógica entre algumas incógnitas em um modelo matemático de um domínio de interesse (Del Palo et al 2007).
8Segundo o autor, é o contexto gerado pela combinação dos três modelos.
também estabelece restrições, por exemplo de que a soma dos comprimentos dos caminhos deve ser mínima. Estas restrições permitem reduzir o custo de execução de testes [41]. Um método foi proposto e implementado que usa modelo para resolver o problema de efetividade de fuzzing [42]. O modelo de SET é extraído com ajuda de técnicas de inferência e o processo de fuzzing é guiado por um algoritmo evolutivo. A técnica de inferência é responsável por interpretar o estado do SET, permitindo realizar o processo de fuzzing a partir de um estado apropriado. O processo evolutivo funciona da seguinte forma: a primeira geração é criada usando sequências de entrada, baseadas em sequências já utilizadas em testes de outros SET. As sequências constituem as várias populações, que evoluem em paralelo, em diferentes grupos. Mutações e cruzamentos são realizados dentro de uma determinada população e entre diferentes grupos. A função de adequação depende dos estados percorridos e das saídas correspondentes. É usado o elitismo para criar a entrada da próxima geração.
Outro método utiliza um modelo de ameaças para gerar automaticamente sequências de teste de segurança [43]. O método consiste em dois passos. O primeiro passo envolve a geração automatizada de sequência de teste a partir de árvores de ameaças. As árvores de ameaças (semelhante a árvore de ataque) são estruturas em árvore com nós filhos com relacionamentos AND ou OR, e descrevem o processo de tomada de decisão pelo qual um invasor passaria para comprometer o software. O nó raiz de uma árvore de ameaças é o objetivo da ameaça. O nó raiz é então decomposto em sub-objetivos (nós filhos) continuando a decompor até que os nós de folha que representam as ações de ataque individuais sejam determinados. As árvores de ameaças descrevem o processo de tomada de decisão pelo qual um invasor passaria para comprometer o software. O segundo passo envolve a transformação dos testes de segurança em casos de testes executáveis. Inicialmente são geradas sequências de teste de segurança a partir de árvores de ameaças e parâmetros de teste a partir das sintaxes de entrada. Em seguida, são integrados os parâmetros de teste nas sequências de teste para criar casos de teste de segurança completos, mas abstratos, i.e., independentes da implementação. Com o conhecimento de implementação, são convertidos, ainda mais, os testes de segurança abstratos para testes de segurança concretos; finalmente são geradas entradas de teste válidas e inválidas para depois gerar scripts de teste que executam todas as sequências de teste com valores de entrada atribuídos [39].
Um método para testes de propriedades de segurança específicas de cartões inteligentes (smart cards) permite a validação do sistema com MBT a partir de esquemas de teste [44].
