Análise de vulnerabilidades

Um aspecto importante nos testes diz respeito à análise de resultados. No caso dos testes de segurança, o objetivo é determinar se vulnerabilidades foram detectadas ou não. É uma tarefa difícil porque não existe uma forma padrão que ajude a determinar a presença ou não de vulnerabilidades nas aplicações. É necessário, de acordo com Vieira et al , 2009 [2] e [54] diferenciar as situações em que a resposta pode acusar uma falha é consequência da exploração bem sucedida de vulnerabilidades ou decorre de defeitos não intencionais no cliente ou no servidor. Em outros termos, o objetivo da análise dos resultados é evitar ou reduzir ao máximo os falsos positivos e falsos negativos.

Para determinar se uma vulnerabilidade foi detectada, vários aspectos devem ser considerados. Por exemplo, para o caso de SQL Injection, deve-se considerar se: houve algum vazamento de dados para atacante; se é possível obter informação sobre a estrutura do banco de dados, ou ainda, se o banco de dados foi corrompido.

No método de Bozic et al., que inspirou este trabalho, a detecção de vulnerabilidades é feita conforme o tipo de vulnerabilidade buscada [4]. No caso de SQLI, o ataque é bem-sucedido quando o SeT recebe uma resposta HTTP contendo dados buscados no banco de dados, como por exemplo, identificação de usuário ou senhas. Dado que os valores exatos são difíceis de determinar automaticamente, cabe ao testador fornecer as respostas esperadas. Durante os testes, um parser analisa as respostas HTTP em busca dos valores passados pelos testadores. Para a detecção de vulnerabilidades de XSS, um parser também é utilizado para buscar elementos adicionais na resposta HTTP, que correspondem às entradas maliciosas fornecidas.

Diferentemente do trabalho que nos serviu de base, utilizamos um conjunto de regras, inspiradas em diversos trabalhos [2, 52]. Descrevemos a seguir as regras para detecção de vulnerabilidades de SQLI, e aquelas para detecção de vulnerabilidades de XSS na seção 3.5.2.

4.5.1. Regras para detecção de vulnerabilidades de SQLI

Para confirmar a existência de uma vulnerabilidade utilizamos o conjunto de regras (e verificações correspondentes) propostas em [2] para classificar as vulnerabilidades detectadas em três grupos: falsos positivos confirmados, vulnerabilidades confirmadas e c)

duvidosas. Vulnerabilidades são classificadas como falsos positivos se atenderem a uma das seguintes condições:

• Se o erro / resposta obtida estiver relacionado a um problema de robustez do aplicativo e não a um comando SQL (por exemplo, um NumberFormatException). • Se o erro / valor na resposta do serviço da Web não é causado pelos dados inseridos

pelos testes. Em outras palavras, o mesmo problema ocorre quando o serviço é executado com entradas válidas.

As vulnerabilidades detectadas são classificadas como vulnerabilidades confirmadas se satisfizerem uma das seguintes condições:

• Se é possível observar que o comando SQL executado foi invalidado devido aos valores fornecidos pelos testes. Nesse caso o comando SQL ou parte dele deve estar incluído na resposta do serviço da Web.

• Se os valores fornecidos levarem o servidor de banco de dados a levantar exceções. • Se for possível aceder a serviços não autorizados ou páginas da web (por exemplo,

quebrando o processo de autenticação usando SQL Injection).

Se nenhuma dessas regras puder ser aplicada, não há como confirmar se uma vulnerabilidade realmente existe ou não. Esses casos são classificados como inconclusivos.

4.5.2. Regras para XSS

No caso de XSS, aplicamos um conjunto de oito regras para analisarmos a resposta dada após a injeção de ataques [54], descritas a seguir:

Regra 1.

Se o cabeçalho da resposta contiver o código "200 OK" E o servidor executou a mensagem SOAP com o ataque XSS, ENTÃO há uma Vulnerabilidade Encontrada (VE) no Serviço da Web. Caso contrário, se a mensagem SOAP descrever a existência de um erro de sintaxe ou aviso sobre a presença de um ataque, ENTÃO não há vulnerabilidade encontrada (VNE) no serviço da Web.

Regra 2.

Se o cabeçalho contiver o código "400 Bad request message", por exemplo, o formato da solicitação é inválido: SOAP obrigatório ausente, ENTÃO não há vulnerabilidade (VNE) no ws.

Se o cabeçalho contiver o código "500 Internal Server Error" E houve divulgação de informações na mensagem SOAP (por exemplo, mostra informações do caminho de diretório, biblioteca de funções e objetos, acesso a banco de dados e arquivos XML com nomes de usuário e senhas, entre outros), ENTÃO há uma vulnerabilidade encontrada (VE), caso contrário não há vulnerabilidade encontrada (VNE) no WS.

Regra 4.

i) Se na ausência de ataques, o cabeçalho contiver o código "500 Internal Server Error" E houver divulgação de informações na mensagem SOAP. E ii) se na presença de ataque XSS10_{, o cabeçalho contiver o código "HTTP 200 OK", ENTÃO há uma Vulnerabilidade}

Encontrada (VE) no WS. Regra 5.

i) Se na ausência de ataques, o cabeçalho contiver o código "500 Internal Server Error" E houve divulgação de informações na mensagem SOAP. E iii) se na presença de ataque XSS11, o cabeçalho contiver o código "400 Bad request message", ENTÃO há uma Vulnerabilidade Encontrada (VF) no WS.

Regra 6

i) Se na ausência de ataques, o cabeçalho contiver o código "500 Internal Server Error" E houve divulgação de informações na mensagem SOAP. E iv) se na presença de ataque XSS, o cabeçalho também contiver o código "500 Internal Server Error", ENTÃO há uma Vulnerabilidade Encontrada (VE) no WS.

Regra 7

Se o servidor não responder, é considerado como falha, ENTÃO o resultado é considerado inconclusivo, porque não pode garantir que o erro foi causado pelo ataque.

Regra 8.

Se nenhuma das regras acima puder ser aplicada, ENTÃO o resultado é considerado inconclusivo, porque não há como confirmar se realmente houve vulnerabilidades no WS.

10_{Significa o teste rodou duas vezes. Primeiro na ausência de ataques e depois na presença de ataques SQLI.} 11_{Tratamento semelhante com a nota anterior.}