43
54 6 TESTES DE SEGURANÇA EM APLICAÇÕES WEB 6.1 Comentários iniciais Este capítulo em toda sua extensão tem como base o guia de testes da OWASP - OWASP Testing Guide Versão 3.0 (MEUCCI, 2008). Tem como objetivo apre- sentar brevemente a metodologia de testes de segurança em aplicações Web da OWASP e não em ser uma descrição total do guia. 6.2 Metodologia de testes Como apresentado no guia de testes, a metodologia de testes de segurança da OWASP é baseada na abordagem caixa preta. De acordo com Mall (2009), nesta abordagem os testes são desenvolvidos sem conhecimento sobre o projeto e código da aplicação a ser testada. Os testes são divididos em dois modos. Modo passivo: nesta etapa o testador tenta entender a lógica da aplicação. Ao final desta etapa o testador pode ter conhecido todos os pontos de acesso da aplicação, tais como: cabeçalhos HTTP, parâmetros, cookies, entre outros. Modo ativo: nesta etapa, a metodologia de testes de invasão da OWASP começa a ser utilizada. Os testes são divididos em nove sub-categorias: teste de autenticação; teste de autorização; teste de lógica de negócios; teste de validação de dados; teste de negação de serviço;

6 TESTESDESEGURANÇAEMAPLICAÇÕES WEBmauriciolyra.pro.br/site/wp-content/uploads/2015/12/03-TESTES-DE... · conhecido, e precisam ser configurados e customizados de acordo com a

Embed Size (px)

Citation preview

Page 1: 6 TESTESDESEGURANÇAEMAPLICAÇÕES WEBmauriciolyra.pro.br/site/wp-content/uploads/2015/12/03-TESTES-DE... · conhecido, e precisam ser configurados e customizados de acordo com a

54

6 TESTES DE SEGURANÇA EM APLICAÇÕES WEB

6.1 Comentários iniciais

Este capítulo em toda sua extensão tem como base o guia de testes da OWASP

- OWASP Testing Guide Versão 3.0 (MEUCCI, 2008). Tem como objetivo apre-

sentar brevemente a metodologia de testes de segurança em aplicações Web da

OWASP e não em ser uma descrição total do guia.

6.2 Metodologia de testes

Como apresentado no guia de testes, a metodologia de testes de segurança da

OWASP é baseada na abordagem caixa preta. De acordo com Mall (2009), nesta

abordagem os testes são desenvolvidos sem conhecimento sobre o projeto e código

da aplicação a ser testada. Os testes são divididos em dois modos.

Modo passivo: nesta etapa o testador tenta entender a lógica da aplicação. Ao

final desta etapa o testador pode ter conhecido todos os pontos de acesso da

aplicação, tais como: cabeçalhos HTTP, parâmetros, cookies, entre outros.

Modo ativo: nesta etapa, a metodologia de testes de invasão da OWASP começa

a ser utilizada. Os testes são divididos em nove sub-categorias:

• teste de autenticação;

• teste de autorização;

• teste de lógica de negócios;

• teste de validação de dados;

• teste de negação de serviço;

Page 2: 6 TESTESDESEGURANÇAEMAPLICAÇÕES WEBmauriciolyra.pro.br/site/wp-content/uploads/2015/12/03-TESTES-DE... · conhecido, e precisam ser configurados e customizados de acordo com a

55

• teste de gerenciamento de configuração;

• teste de gerenciamento de sessão;

• teste de Ajax;

• teste de web service;

O modo passivo, que é a coleta de informações, e todas as sub-categorias do

modo ativo serão detalhas nas seções a seguir.

6.3 Coleta de informações

A primeira fase a ser realizada em um teste de segurança de uma aplicação

Web é a coleta de informações. É preciso reunir tantas informações quanto possí-

vel sobre a aplicação que será avaliada. Diversas ferramentas podem ser usadas,

tais como: mecanismos de busca, scanners, ferramentas para envio de requisições

HTTP, entre outras. Nas próximas subseções serão apresentados algumas formas

para coletar informações que auxiliarão no teste.

6.3.1 Identificação de robots

Os robots, também chamados de spiders e crawlers, são programas criados

para visitar URLs de sites de forma automatizada. A partir de uma lista de URLs,

varrem a página e buscam outros URLs, essas novas encontradas são adicionadas à

lista para posteriormente também serem visitadas. São usados por buscadores Web

para fazer a indexação das páginas para as buscas e por spammers para capturar

endereços de e-mail automaticamente.

Page 3: 6 TESTESDESEGURANÇAEMAPLICAÇÕES WEBmauriciolyra.pro.br/site/wp-content/uploads/2015/12/03-TESTES-DE... · conhecido, e precisam ser configurados e customizados de acordo com a

56

O comportamento dos robots é especificado pelo Protocolo de Exclusão de

Robôs (Robots Exclusion Protocol) no arquivo robots.txt. Este arquivo auxilia

o testador na identificação da estrutura de diretórios da aplicação a ser avaliada, e,

caso exista, pode ser localizado no diretório Web raíz. Um exemplo é apresentado

na sequência.

User-agent: *

# Directories

Disallow: /includes/

Disallow: /misc/

# Files

Disallow: /CHANGELOG.txt

Disallow: /cron.php

Uma descrição detalhada das diretivas que configuram a maneira de como

as aplicações ou sites são varridos por um robot pode ser encontrada em: http:

//www.robotstxt.org/.

6.3.2 Descoberta em motores de busca

Considerando o mecanismo de busca do Google, assim que o robot termina de

varrer o conteúdo de um site, um índice de páginas é compilado para ser usado no

processo de buscas. Se nenhuma especificação de comportamento para os robots

foi definida, é possível que toda aplicação esteja indexada. Isto habilita o testador

a encontrar mais informações sobre tal aplicação, incluindo diretórios e páginas

usados pelos administradores.

Page 4: 6 TESTESDESEGURANÇAEMAPLICAÇÕES WEBmauriciolyra.pro.br/site/wp-content/uploads/2015/12/03-TESTES-DE... · conhecido, e precisam ser configurados e customizados de acordo com a

57

No mecanismo de busca do Google, a descoberta de conteúdos pode ser feita

usando operadores avançados de pesquisa. Para obter resultados de apenas um

domínio específico pode-se usar o operador site da seguinte forma:

site:www.seusite.com.br

Mais sobre os operadores avançados de busca do Google podem ser encontra-

dos no endereço: http://support.google.com/websearch/bin/answer.py?

hl=en&answer=136861.

6.3.3 Identificação de pontos de entrada

A identificação dos pontos de entrada ajuda a reconhecer prováveis pontos de

fraqueza da aplicação. Uma maneira para identificá-los é observar como navegador

Web se comunica com a aplicação. Enquanto se navega pela aplicação é preciso dar

atenção a todas requisições HTTP e aos parâmetros que são enviados e recebidos.

Nas requisições HTTP pode-se usar tanto o método GET quanto o método

POST para passar parâmetros à aplicação. A principal diferença entre esses dois

métodos é que o método GET usa o URL para realizar a passagem de parâmetros.

Já o método POST passa os parâmetros no corpo da requisição HTTP. Assim para

identificar os parâmetros em requisições usando POST é preciso usar um proxy, tal

como o aplicativo WebScarab apresentado no Seção 5.2.

Ainda em requisições usando POST, é importante dar atenção aos campos es-

condidos de formulários. Esses campos não são vistos na página Web, para vê-los

é preciso analisar o código-fonte HTML. Frequentemente tais campos possuem

informações sensíveis, como quantidade de itens no carrinho de compras, valor da

compra, entre outros. Usando um proxy é possível analisar todos os parâmetros

Page 5: 6 TESTESDESEGURANÇAEMAPLICAÇÕES WEBmauriciolyra.pro.br/site/wp-content/uploads/2015/12/03-TESTES-DE... · conhecido, e precisam ser configurados e customizados de acordo com a

58

passados à aplicação, incluindo os campos escondidos, e também alterá-los an-

tes de serem enviados. O código fonte de um campo escondido é apresentado na

sequência:

<input type="hidden" name="parametro_nome" value="valor_do_parametro" />

Em relação as requisições HTTP, é importante verificar quais requisições

usam GET e quais usam POST, identificar os paramêtros em ambas requisições, não

deixando de lado os parâmetros passados usando os campos escondidos nas requi-

sições POST. E em relação as respostas HTTP, é importante verificar onde cookies

são criados e modificados e onde existem quaisquer tipos de redirecionamentos,

em especial 403 Forbidden e 500 Internal Server Errors.

6.3.4 Avaliação da assinatura do servidor Web

Conhecer o tipo e a versão do servidor Web na qual a aplicação esta sendo

executada ajuda significativamente, pois capacita o testador a identificar vulnera-

bilidades já conhecidas e escolher os métodos adequados para ser usados durante

os testes.

A avaliação da assinatura do servidor Web pode ser feita automaticamente por

ferramentas de segurança. O aplicativo httprint é uma ferramenta indicada para

este tipo de avaliação. Ele possui um banco de assinaturas e a partir dele reconhece

o tipo e versão do servidor em uso. Mais informações sobre o httprint podem ser

encontradas na página http://net-square.com/httprint/index.shtml.

Page 6: 6 TESTESDESEGURANÇAEMAPLICAÇÕES WEBmauriciolyra.pro.br/site/wp-content/uploads/2015/12/03-TESTES-DE... · conhecido, e precisam ser configurados e customizados de acordo com a

59

6.3.5 Análise de códigos de erros

Em testes de segurança é comum deparar-se com diversas mensagens de erros

que são geradas pelas aplicações Web ou pelos servidores Web. Tais erros são de

grande serventia aos testadores pois podem revelar informações sobre bases de

dados, bugs e outros componentes diretamente ligados às aplicações e servidores.

Um exemplo prático de informações que são descobertas através de mensa-

gens de erros é apresentado na sequência:

telnet www.ufla.br 80

Trying 200.131.250.54...

Connected to site.ufla.br.

Escape character is ’^]’.

GET /pagina_errada.php HTTP/1.1

HTTP/1.1 400 Bad Request

Date: Thu, 15 Mar 2012 16:45:15 GMT

Server: Apache/2.2.16 (Fedora)

Content-Length: 304

Connection: close

Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">

...

<address>Apache/2.2.16 (Fedora) Server at site.ufla.br Port 80</address>

...

Page 7: 6 TESTESDESEGURANÇAEMAPLICAÇÕES WEBmauriciolyra.pro.br/site/wp-content/uploads/2015/12/03-TESTES-DE... · conhecido, e precisam ser configurados e customizados de acordo com a

60

Tanto no campo Server da requisição quanto na página HTML retornada são

exibidas informações sobre o servidor Web e também sobre o sistema operacional

sobre qual o servidor Web esta sendo executado.

6.4 Teste de autenticação

Autenticação é o ato de estabelecer ou confirmar algo, ou alguém, como au-

têntico. Em segurança computacional, autenticação é o processo de tentar verificar

a identidade digital do remetente de uma comunicação. Testar esquemas de auten-

ticação implica em conhecer como funciona o processo de autenticação e usar tal

conhecimento para burlar o mecanismo.

Em aplicações Web, o mais comum é o uso de formulários HTML para re-

alizar a autenticação. Com seu uso é possível implementar um esquema mais

sofisticado de autenticação em relação aos esquemas de autenticação baseados no

protocolo HTTP (Basic e Digest Access Authentication). Um formulário simples

de autenticação é apresentado na sequência.

<form method="POST" action="login.php">

<input type="text" name"username">

<input type="password" name="password">

</form>

Os próximos capítulos abordarão os testes para avaliar a segurança do pro-

cesso de autenticação de aplicações Web.

Page 8: 6 TESTESDESEGURANÇAEMAPLICAÇÕES WEBmauriciolyra.pro.br/site/wp-content/uploads/2015/12/03-TESTES-DE... · conhecido, e precisam ser configurados e customizados de acordo com a

61

6.4.1 Transporte de credênciais através de um canal criptografado

Testar o transporte das credênciais de usuários significa verificar como os da-

dos de autenticação são enviados para o servidor da aplicação. Usar uma conexão

criptografada evita que os dados sejam interceptados por usuários maliciosos.

O foco deste teste é avaliar se a aplicação Web tomas as medidas necessárias

para evitar interceptações de dados. O testador irá então verificar se os dados inse-

ridos e enviados em formulários Web são transmitidos usando protocolos seguros,

tal como HTTPS.

A verificação é feita usando um web proxy para analisar as mensagens de re-

quisição da aplicação Web. Se o campo do URL da linha de requisição, que é a

primeira linha de uma mensagem de requisição HTTP, possuir um URL especi-

ficando o protocolo HTTP então pode-se entender que os dados serão enviados

sem criptografia. Um exemplo mostrando uma linha de requisição usando HTTP

é apresentado na sequência:

POST http://www.example.com/AuthenticationServlet HTTP/1.1

Para um transporte seguro de dados deve-se usar o protocolo HTTPS. A linha

de requisição ao usar este protocolo é mostrada a seguir:

POST https://www.example.com:443/cgi-bin/login.cgi HTTP/1.1

É possível verificar que o campo do URL especifica o uso do protocolo HTTPS,

que usa vias criptografadas para o tráfego de informações, e impossibilita a leitura

dos dados por terceiros.

Page 9: 6 TESTESDESEGURANÇAEMAPLICAÇÕES WEBmauriciolyra.pro.br/site/wp-content/uploads/2015/12/03-TESTES-DE... · conhecido, e precisam ser configurados e customizados de acordo com a

62

6.4.2 Avaliação da enumeração de usuários

Existem aplicações Web que, por algum erro de configuração ou por alguma

decisão de projeto, revelam quando um login existe ou não na aplicação. Desta

forma, o objetivo deste teste é verificar se ao interagir com o mecanismo de auten-

ticação é possível obter um conjunto de usuários válidos. Este conjunto pode ser

usado em um ataque de força bruta, assunto abordado em capítulo posterior.

O testador irá enviar diferentes combinações de usuários e senhas e então

observar a resposta da aplicação. A Tabela 1 mostra as situações possíveis para

esta interação.

Tabela 1: Situações possíveis para enumeração de usuários.Usuário Senha Resposta da aplicação

Situação 1 Correto Incorreto A senha informada não está correta.Situação 2 Incorreto Incorreto Usuário não reconhecido.

A Situação 1 deixa a entender que o usuário informado está correto. Assim

esta aplicação é vulnerável a enumeração de usuários, logo pode-se enviar entradas

diferentes para o usuário e observar a resposta da aplicação. De acordo com esta

situação é possível criar um conjunto de usuários válidos. Já a Situação 2 mostra

que o usuário informado não é reconhecido na aplicação.

Informações que podem ajudar na enumeração de usuários podem ser vistas

também nos títulos das páginas, em páginas de recuperação de senha e também

em códigos de erros do protocolo HTTP.

É importante saber que dependendo da política da aplicação, ao realizar diver-

sas tentativas de “adivinhação” de usuários e senhas, pode ocorrer de contas serem

bloqueadas ou ter o IP bloqueado no firewall do servidor.

Page 10: 6 TESTESDESEGURANÇAEMAPLICAÇÕES WEBmauriciolyra.pro.br/site/wp-content/uploads/2015/12/03-TESTES-DE... · conhecido, e precisam ser configurados e customizados de acordo com a

63

6.4.3 Conta padrão de usuário

A maioria das aplicações Web são hospedadas em infraestruturas populares.

O conjunto de software que é usado para que uma aplicação Web funcione é bem

conhecido, e precisam ser configurados e customizados de acordo com a neces-

sidade da aplicação. Também diversos dispositivos de hardware, roteadores de

rede, servidores de banco de dados, entre outros, possuem interfaces Web para

configuração e administração. O problema envolvendo as aplicações e conjunto

de hardware citados refere-se às credênciais de autenticação que são fornecidas

para uma autenticação inicial e de configuração. Frequentemente eles não são de-

vidamente configurados e as combinações login/senha padrões são mantidas ativas

em aplicações que estão em produção.

A causa deste problema pode ser identificada como:

• profissionais de TI34 inexperientes que desconhecem a importância de alte-

rar login/senha padrão;

• administradores e usuários de aplicações Web que usam senhas fracas;

• aplicações que vazam informações quanto a validade do login durante ten-

tativas de autenticação;

O teste para este tipo de problema é feito tentando encontrar combinações

usando credênciais padrões como: (1) admin; (2) administrator; (3) root; (4) sys-

tem; (5) guest; (6) operator. Dependendo do tipo de aplicação que esta sendo

testada, pode-se usar tais valores em português.

34Tecnologia da Informação

Page 11: 6 TESTESDESEGURANÇAEMAPLICAÇÕES WEBmauriciolyra.pro.br/site/wp-content/uploads/2015/12/03-TESTES-DE... · conhecido, e precisam ser configurados e customizados de acordo com a

64

Outra situação possível é relacionar o nome da empresa proprietária da aplica-

ção Web com a credêncial. E também verificar na página responsável pelo registro

de novos usuários quais são as regras, tais como caracteres válidos, número má-

ximo de caracteres, entre outros, para a criação de login e senha. Isto pode diminuir

as possibilidades a serem testadas.

Alguns sites possuem um banco de senhas padrões e podem ser usados para

auxiliar no processo de “adivinhação” de credênciais da aplicação que esta em

teste. O site http://www.virus.org/default-password/ possui senhas para

diversos dispositivos de rede.

6.4.4 Teste de força bruta

A idéia de um ataque usando força bruta é enumerar todos os possíveis can-

didatos a solução de um problema e checar quando cada um deles o satisfaz. No

contexto de aplicações Web, o ataque consiste em conseguir uma conta de usuá-

rio válida para acessar áreas restritas da aplicação. Se obtiver êxito, ou seja, se

conseguir uma credêncial válida, o atacante poderá acessar áreas que possuem da-

dos pessoais dos usuários, tais como, documentos, dados bancários, entre outros.

Também pode ser possível acessar a área gerencial da aplicação.

A grande maioria das aplicações têm optado por usar métodos de autenticação

baseados em formulário HTML, pois dão maior liberdade para implementar meca-

nismos mais eficientes e seguros de autenticação a usar os métodos de autenticação

providos pelo protocolo HTTP (Basic e Digest).

Diversas maneiras para realizar o ataque usando força bruta podem ser usa-

das, tais como: (1) ataque de dicionário; (2) ataque de busca; (3) ataque de busca

baseado em regras. Os ataques de dicionários são feitos por ferramentas que usam

Page 12: 6 TESTESDESEGURANÇAEMAPLICAÇÕES WEBmauriciolyra.pro.br/site/wp-content/uploads/2015/12/03-TESTES-DE... · conhecido, e precisam ser configurados e customizados de acordo com a

65

dicionários com palavras que possivelmente são usadas pelo usuário da conta. O

ataque de busca é aquele que tenta cobrir todas as possibilidades possíveis com

base em um conjunto de caracteres e tamanho de senha. Afim de reduzir o tempo

de execução do ataque anterior pode-se usar regras para gerar os candidatos, ca-

racterizando o ataque de busca baseado em regras.

O programa THC Hydra35 pode ser usado para executar ataques de força bruta

tanto em esquemas de autenticação usando formulários HTML quanto usando au-

tenticação HTTP.

6.4.5 Contorno do esquema de autenticação

Aplicações Web podem possuir um esquema de autenticação que não forneça

a segurança adequada, ou seja, que não seja capaz de garantir o devido controle

para o acesso às áreas restritas. Isto pode dar brecha para um atacante ignorar o

esquema de autenticação, habilitando-o a acessar páginas que deveriam ser aces-

sadas somente após uma autenticação realizada com sucesso.

Algumas maneiras para ignorar o esquema de autenticação são apresentadas

na sequência.

Requisição direta de página: caso a aplicação faça o controle de acesso apenas

na página de login, o esquema de autenticação pode ser ignorado ao requi-

sitar as páginas de forma direta. Pode-se acessar, por exemplo, a página

http://www.exemplo.com.br/painel.php, pois a verificação de login

foi feita, erroneamente, apenas para a página http://www.exemplo.com.

br/login.php.

35http://www.thc.org/thc-hy

Page 13: 6 TESTESDESEGURANÇAEMAPLICAÇÕES WEBmauriciolyra.pro.br/site/wp-content/uploads/2015/12/03-TESTES-DE... · conhecido, e precisam ser configurados e customizados de acordo com a

66

Modificação de parâmetros: também é possível que uma determinada aplicação

use apenas um cookie para controlar o acesso às áreas restritas. Tal cookie

pode ser da seguinte forma: autenticado=sim. O testador pode mudar o

valor do cookie e então será reconhecido como autenticado pela aplicação.

Desta forma, a função do testador é avaliar se existe alguma situação, na apli-

cação sendo testada, parecida com as situações descritas acima. Se sim, a aplicação

é vulnerável e seu esquema de autenticação pode ser contornado.

6.4.6 Vulnerabilidades em Esqueci minha senha e Lembrar senha

No mecanismo de autenticação de aplicações Web é comum encontrarmos pá-

ginas específicas para recuperar ou redefinir senhas, e também a funcionalidade de

lembrar senha. Esta provê comodidade aos usuários, pois permite acessos posteri-

ores sem a necessidade de digitar a senha. Estes recursos podem inserir falhas no

processo de autenticação.

Em relação a função Esqueci minha senha, na maioria das vezes o processo

para recuperar ou redefinir senhas é feito enviando a nova senha ou link para redefi-

nição de senha para o e-mail vinculado ao usuário. Percebe-se que isto implica que

a aplicação confia totalmente na segurança do e-mail do usuário. Outra possibili-

dade é o uso de perguntas de segurança. Elas devem ser respondidas corretamente

para prosseguir com a recuperação (redefinição) da senha.

Caso seja usado perguntas de segurança, pode-se então usar engenharia social

para tentar obter a resposta da vítima. Para o processo de adivinhação da resposta

é necessário ter em mente que a aplicação pode bloquear o mecanismo de recupe-

ração após um determinado número de tentativas. Em relação a função Lembrar

Page 14: 6 TESTESDESEGURANÇAEMAPLICAÇÕES WEBmauriciolyra.pro.br/site/wp-content/uploads/2015/12/03-TESTES-DE... · conhecido, e precisam ser configurados e customizados de acordo com a

67

senha, é necessário avaliar o uso de cookies, pois podem ser usados para armazenar

as credenciais do usuário.

6.4.7 Avaliação do mecanismo de logout

A função de logout tem como objetivo encerrar todas as sessões do usuário

com a aplicação e garantir que tais sessões serão destruídas e inutilizadas. Desta

forma, este teste visa avaliar a possibilidade de reusar uma sessão após o processo

de logout.

O processo de logout em aplicações Web ocorre após dois tipos de eventos:

(1) o usuário encerra sua sessão (logout); (2) o usuário é automaticamente des-

logado pela aplicação por inativadade (timeout logout). Se este processo não é

executado de forma correta, um atacante pode ressucitar uma sessão de um usuá-

rio real e então obter acesso à aplicação.

O teste mais simples a ser realizado no processo de logout é clicar no botão

Voltar do navegador Web e então checar se o usuário ainda esta logado na aplica-

ção. Caso seja possível apenas visualizar páginas anteriores e não posteriores, isto

é, novas páginas, significa que as páginas estão no cache do navegador.

Outra situação para teste é verificar o cookie após o logout e então restaurar o

valor do cookie para seu estado inicial. Feito isto é necessário checar se o usuário

ainda está logado na aplicação. Se sim, implica que a aplicação não faz controle

de cookies ativos e inativos, e apenas as informações armazenadas no cookie são

necessárias para garantir o acesso à aplicação.

Para o caso do usuário ser deslogado por inatividade (timeout logout), o teste é

realizado checando quando o mecanismo existe e confirmando se todas as sessões

Page 15: 6 TESTESDESEGURANÇAEMAPLICAÇÕES WEBmauriciolyra.pro.br/site/wp-content/uploads/2015/12/03-TESTES-DE... · conhecido, e precisam ser configurados e customizados de acordo com a

68

do usuário são apagadas ou inutilizadas após o timeout. Neste caso é preciso enten-

der quando o logout é forçado pelo cliente ou pelo servidor. Se o cookie de sessão

possui informações relacionadas ao tempo (horário de acesso, último acesso, etc),

implica que o cliente esta envolvido com o processo de forçar o encerramento da

sessão do usuário. Se este for o caso, é preciso alterar tais valores no cookie de

sessão e avaliar se a sessão do usuário na aplicação foi prolongada.

Por fim, o fato de deslogar de uma aplicação não significa que o cache do

navegador Web será apagado. É importante avaliar quando informações sensíveis

são vazadas para o navegador.

6.4.8 Avaliação do CAPTCHA

CAPTCHA (Completely Automated Public Turing test to tell Computers and

Humans Apart) [Teste de Turing público completamente automatizado para dife-

renciação entre computadores e humanos] é um teste usado para garantir que as

ações em uma determinada aplicação não é gerada por um computador. A efi-

ciência do CAPTCHA está em evitar ações automatizadas em páginas de login,

registro de usuários, postagens em blogs, entre outros.

O teste para este tipo de mecanismo faz uso de um proxy Web para identificar

todos os parâmetros que são enviados do cliente para o servidor juntamente com

o CAPTCHA decodificado (valor digitado pelo usuário). Isto é feito pois podem

existir parâmetros que possuem o valor do CAPTCHA decodificado. Outra possi-

bilidade é tentar enviar um CAPTCHA decodificado anteriormente (já usado) com

seu respectivo identificador. Caso for aceito, então é possível ignorar o mecanismo

de CAPTCHA da aplicação.

Page 16: 6 TESTESDESEGURANÇAEMAPLICAÇÕES WEBmauriciolyra.pro.br/site/wp-content/uploads/2015/12/03-TESTES-DE... · conhecido, e precisam ser configurados e customizados de acordo com a

69

6.5 Teste de autorização

Autorização é o processo que segue após uma tentativa de autenticação com

sucesso. É nesta etapa que as permissões de acesso aos recursos da aplicação Web

serão concedidas. Para este teste o testador precisará de credênciais válidas.

6.5.1 Teste de passagem de diretório

Servidores Web usam um diretório raiz para manter os arquivos e dados de

aplicações Web. Este diretório é a base na hierarquia da aplicação Web. O teste de

passagem de diretório (directory traversal), também conhecido como ataque dot-

dot-slash (../) e como escalada de diretório, permite que atacantes visualizem

diretórios e arquivos que supostamente não deviam visualizar, como exemplo o

arquivo /etc/passwd em plataformas baseadas em Linux.

O teste é feito verificando partes da aplicação que aceitam conteúdos vindos

do usuário e posteriormente verificando se tal conteúdo é validado de forma segura.

Como exemplo o URL:

http://www.exemplo.com/perfil_usuario.php?item=pagina.html

A página perfil_usuario.php irá carregar informações vindas do arquivo

pagina.html. Se a validação da variável item não for feita adequadamente é

possível então carregar o arquivo citado anteriormente (/etc/passwd) usando a

notação para retroceder um ou mais diretórios: ../../../etc/passwd.

Outra situação possível é incluir arquivos ou scripts vindos de outros sites, tal

como:

Page 17: 6 TESTESDESEGURANÇAEMAPLICAÇÕES WEBmauriciolyra.pro.br/site/wp-content/uploads/2015/12/03-TESTES-DE... · conhecido, e precisam ser configurados e customizados de acordo com a

70

http://www.exemplo.com/index.php?arquivo=owasp.org/malicioso.txt

No guia de testes da OWASP pode-se encontrar as diferentes codificações que

representam a notação para retroceder diretórios, além de listar os diferentes ca-

racteres separadores de diretórios nos diversos sistemas operacionais.

6.5.2 Burlagem do esquema de autorização

Este teste foca em avaliar como o esquema de autorização foi implementado

para cada regra de acesso a funções e recursos da aplicação Web. A avaliação cir-

cunda a seguinte questão: é possível acessar recursos e funções que supostamente

era para ser acessadas apenas por um tipo de usuário?

Usando a página adicionaUsuario.php como exemplo, suponha que ela faz

parte das funções administrativas de uma aplicação Web. Ao executar a função

para adicionar usuários, a seguinte requisição HTTP é gerada:

POST /admin/adicionaUsuario.php HTTP/1.1

Host: www.exemplo.com.br

[outros cabeçalhos HTTP]

userID=fakeuser&role=3&group=grp001

É preciso avaliar o que acontece se um usuário sem privilégios administrativos

enviar tal requisição. O usuário será criado? Será possível logar como tal usuário?

Se caso for possível, a aplicação é vulnerável e seu mecanismo de autorização é

falho, ou seja, pode ser ignorado.

Page 18: 6 TESTESDESEGURANÇAEMAPLICAÇÕES WEBmauriciolyra.pro.br/site/wp-content/uploads/2015/12/03-TESTES-DE... · conhecido, e precisam ser configurados e customizados de acordo com a

71

6.6 Avaliação da lógica de negócios

Testar falhas na lógica de negócios requer pensar de forma não convencional

e tal teste não pode ser feito de forma automática por ferramentas de segurança.

É preciso realizar uma análise profunda na aplicação e depende da habilidade e

criatividade do testador. Cada caso é específico de cada aplicação.

Para ilustrar a situação de uma falha lógica, considere uma loja virtual onde o

cliente adiciona créditos na conta e então pode comprar usando estes créditos. O

processo feito pelo cliente para realizar uma compra seria:

1. adiciona creditos em sua conta;

2. busca produto ou lista diversos produtos;

3. adiciona produto no carrinho – nesta etapa a aplicação subtrai o valor do

produto do total de créditos do cliente;

4. procede os passos de finalização da compra;

A lógica da aplicação seria basicamente a descrita acima. Uma falha (na ló-

gica de negócios) seria o usuário informar um valor negativo para o número de

itens e ter o valor do produto somado aos seus créditos.

Apesar de ser considerado uma arte, a descoberta de falhas lógicas, pode se-

guir os seguintes passos:

Conhecimento da aplicação: como as falhas são intrinsecamente ligadas a apli-

cação, ou seja, depende de como ela foi desenvolvida e como funciona, é

Page 19: 6 TESTESDESEGURANÇAEMAPLICAÇÕES WEBmauriciolyra.pro.br/site/wp-content/uploads/2015/12/03-TESTES-DE... · conhecido, e precisam ser configurados e customizados de acordo com a

72

preciso possuir um grande entendimento sobre a aplicação. Tal conheci-

mento pode ser obtido através dos documentos que descrevem as funciona-

lidades, manuais, casos de uso, entre outros.

Coletagem dos dados: o testador precisa reunir informações sobre a aplicação,

tais informações são extraídas nas seguintes situações: (1) cenários da apli-

cação; (2) fluxos de trabalho; (3) grupos de usuários e seus privilégios;

(4) grupos de departamentos. Tais dados são essenciais para modelar os

testes lógicos.

Modelagem dos testes lógicos: a partir dos dados coletados, o testador precisa

modelar um teste para cada privilégio listado. E então verificar se alguma

ação pode ser executada por um grupo que não possui privilégio para executá-

la. Outra situação é navegar em ações que são projetadas passo a passo, fo-

cando em iniciar pelo meio do processo e observando o comportamento da

aplicação.

Execução dos testes: nesta etapa é preciso observar as requisições HTTP, suas

sequências, os campos escondidos de formulários, parâmetros, entre outros

detalhes.

Este tipo de falha é muito perigosa, mais difícil de ser detectada, uma vez que

não é possível realizar uma avaliação de forma automatizada. Outro ponto é que

o teste para este tipo depende da experiência do testador e sua criativadade em

manipular a aplicação.

Page 20: 6 TESTESDESEGURANÇAEMAPLICAÇÕES WEBmauriciolyra.pro.br/site/wp-content/uploads/2015/12/03-TESTES-DE... · conhecido, e precisam ser configurados e customizados de acordo com a

73

6.7 Testando a validação de dados

Uma das premissas mais básicas em relação a segurança de aplicações em

geral é: “Nunca confiar nas entradas do usuário”. A falta de validação dos dados

vindos do usuário pode conduzir a diversas vulnerabilidades, como: Cross Site

Scripting, SQL Injection, entre outras. Desta forma, este teste tem como objetivo

avaliar se as entradas do usuário são suficientemente validadas antes de serem

usadas.

6.7.1 Testando XSS não-persistente

O Cross Site Scripting (XSS), como já abordado anteriormente, é a possibili-

dade de manipular os parâmetros de entrada de uma aplicação Web para gerar uma

saída maliciosa.

O XSS não-persistente, também conhecido como Reflected Cross Site Scrip-

ting, é aquele na qual a vítima carrega um URL ofensivo, ou seja, o ataque não é

iniciado com o carregamento da aplicação vulnerável. Ele é iniciado com a ação

de clicar em um link que possui parâmetros modificados e que levam a ações não

desejadas. Este é o tipo mais frequente de ataque XSS. Os passos básicos para exe-

cutar este ataque é modelar um URL malicioso e posteriormente convecer a vítima

a acessá-lo.

Para o teste é necessário identificar os pontos de entrada e criar URLs malici-

osas que apontam que tal ponto de entrada é vulnerável. Diferente do testador, que

após identificar a vulnerabilidade irá reportar a falha, o atacante irá criar um URL

que possa causa danos maiores à aplicação, seus dados e seus usuários.

Page 21: 6 TESTESDESEGURANÇAEMAPLICAÇÕES WEBmauriciolyra.pro.br/site/wp-content/uploads/2015/12/03-TESTES-DE... · conhecido, e precisam ser configurados e customizados de acordo com a

74

Como exemplo considere um site que exibe uma mensagem de agradecimento

e posteriormente um link para download de um arquivo. A partir do URL:

http://www.exemplo.com.br/download.php?user=Tulio

O site irá personalizar a mensagem de agradecimento. Se o site mostrar um popup

após o carregamento do URL:

http://www.exemplo.com.br/download.php?user=<script>alert(12)</script>

Implica que tal site é vulnerável, pois foi possível inserir códigos JavaScript no

parâmetro da aplicação. Se uma popup aparecer, ação feita com o trecho de código

acima, significa que a entrada não foi validada e códigos maliciosos podem ser

passados a aplicação.

As possibilidades a partir deste ponto são diversas. Pode-se alterar o link do

arquivo que seria baixado pelo usuário, pode-se carregar um arquivo JavaScript

que esta em outro servidor, entre outras. É importante notar que a validação da

entrada deve ocorrer em diferentes codificações, pois pode-se filtrar <script>,

mas pode-se não filtrar %3cscript%3e. Ambos representam a mesma entrada,

porém em codificações diferentes.

A ferramenta XSS-Proxy36 é uma poderosa ferramenta para ataques XSS e

pode ser usada para auxiliar nos testes.

6.7.2 Testando XSS persistente

Aplicações Web que permitem que os usuários armazenem dados são poten-

cialmente expostas ao XSS persistente. Este tipo ocorre quando a aplicação reune

36http://xss-proxy.sourceforge.net/XSS-Proxy

Page 22: 6 TESTESDESEGURANÇAEMAPLICAÇÕES WEBmauriciolyra.pro.br/site/wp-content/uploads/2015/12/03-TESTES-DE... · conhecido, e precisam ser configurados e customizados de acordo com a

75

os dados do usuário e então os armazena para uso posterior. O fato é que se a en-

trada não for devidamente filtrada, os dados, que podem possuir ações maliciosas,

aparecerão como parte da aplicação e consequentemente serão executados com os

mesmos privilégios da aplicação. Assim sendo, este ataque é considerado bastante

perigoso.

O teste consiste em identificar os pontos onde a entrada fornecida pelo usuá-

rio é armazenada e posteriormente exibida na aplicação. Tais pontos podem ser

encontrados em páginas de “Perfil do Usuário”, que permite alterar nome, sobre-

nome, foto, etc. Lojas online que possuem carrinho de compras, os dados são

armazenado e mostrados posteriormente.

Considere o seguinte trecho HTML:

<input type="text" name="email" value="[email protected]" />

O testado então deve tentar injetar código fora da tag input. Um exemplo

básico é tentar digitar o valor a seguir no campo input:

[email protected]"><script>alert(document.cookie)</script>

Se a entrada não for filtrada, esse valor sera armazenado e toda vez que a

página que exibe o e-mail do usuário for carregada, o script será automaticamente

carregado e exibirá um popup com o valor dos cookies. Caso ao submeter os dados

e a palavra script for simplesmente apagada, isto indica que é possível ter algum

tipo de tratamento para estas entradas maliciosas.

É recomendado que os testadores chequem o RSnake37, este site disponibiliza

uma lista extensa de ataques XSS e maneiras de burlar os filtros XSS.

37RSnake: "XSS (Cross Site Scripting) Cheat Sheet- http://ha.ckers.org/xss.html

Page 23: 6 TESTESDESEGURANÇAEMAPLICAÇÕES WEBmauriciolyra.pro.br/site/wp-content/uploads/2015/12/03-TESTES-DE... · conhecido, e precisam ser configurados e customizados de acordo com a

76

6.7.3 SQL Injection

O ataque SQL Injection consiste em manipular a entrada de dados da aplicação

e enviar instruções SQL com o objetivo de invalidar a lógica feita pelo desenvol-

vedor. Um ataque com sucesso pode retornar ao atacante diversas informações

sensíveis do banco de dados, além de poder permitir a manipulação dos dados,

operações como ‘inserir’, ‘editar’ e ‘deletar’.

O primeiro passo do teste é verificar em quais partes a aplicação se conecta a

um banco de dados. Páginas de autenticação, de busca, de listagem de produtos,

entre outras, são fortes candidatas a usarem uma conexão com banco de dados. O

testador então precisa listar todos os campos de entrada e posteriormente avaliá-

los separadamente, pois um determinado campo pode estar protegido contra SQL

Injection porém outro campo do mesmo formulário pode não estar protegido.

Os testes mais simples feitos nestes campos é usar aspa simples (’) ou um

ponto e vírgula (;). O primeiro é usado como terminador de string e o segundo

como terminador de instrução. Ambos são usados para gerar erros. Uma men-

sagem de erro não tratada pode revelar informações importantes que auxiliam no

prosseguimento do teste.

Considere a seguinte instrução:

SELECT * FROM Users WHERE Username=’$username’ AND

Password=’$password’

Esta consulta é usada para autenticar usuários. Caso ela retorne algum valor

significa que as credênciais passadas existem e o acesso será liberado. Caso não

retorne, significa que não existe e o acesso não será permitido.

Page 24: 6 TESTESDESEGURANÇAEMAPLICAÇÕES WEBmauriciolyra.pro.br/site/wp-content/uploads/2015/12/03-TESTES-DE... · conhecido, e precisam ser configurados e customizados de acordo com a

77

Se o testador enviar tais valores:

$username = 1’ or ’1’ = ’1

$password = 1’ or ’1’ = ’1

E os dados usados na consulta não forem filtrados, a consulta resultante será:

SELECT * FROM Users WHERE Username=’1’ OR ’1’ = ’1’ AND

Password=’1’ OR ’1’ = ’1’

Isto invalida a lógica que deveria ser usada para autenticar usuários e com esta

entrada o acesso será permitido, mesmo a aplicação não conhecedo os verdadeiros

valores de username e password.

Outra categoria de SQL Injection é chamada de Blind SQL Injection. Nesta

variação o testador irá fazer consultas de inferências, tentando obter caracter por

caracter um determinado campo. Com base no comportamento da aplicação ele

poderá inferir se o caracter testado está ou não correto. Esta variação é usada no

caso em que a entrada não é validada corretamente porém a mensagem de erro para

a consultas com injeção de instruções SQL não revelam nada sobre a estrutura da

consulta no banco de dados. É um tipo mais trabalhoso de teste e pode ser usado

ferramentas para automatizar o processo. Mais sobre Blind SQL Injection pode ser

encontrado em (SPETT, 2003).

É importante notar que os ataques do tipo SQL Injection podem variar de

SGBD38 para SGBD, assim o Guia de Testes da OWASP apresenta seções especí-

ficas para cada tipo de sistema.

38Sistema Gestor de Base de Dados

Page 25: 6 TESTESDESEGURANÇAEMAPLICAÇÕES WEBmauriciolyra.pro.br/site/wp-content/uploads/2015/12/03-TESTES-DE... · conhecido, e precisam ser configurados e customizados de acordo com a

78

6.7.4 XML Injection

Seja uma aplicação que usa XML para registrar usuários na aplicação. Isto é

feito adicionando um novo nó <user> no arquivo XML exemplificado a seguir:

<?xml version="1.0" encoding="ISO-8859-1"?>

<users>

<user>

<username>gandalf</username>

<password>!c3</password>

<userid>0<userid/>

<mail>[email protected]</mail>

</user>

</users>

Desta forma, o usuário irá preencher um formulário HTML, a aplicação receberá

os dados digitados e então adicionará o novo nó.

O problema relacionado ao uso do XML esta na possível falta de validação

dos dados que serão adicionados ao arquivo XML na estrutura especificada. Neste

exemplo a estrutura usa as tags <username>, <password>, <userid> e <mail>. O

usuário preencherá os campos username, password e mail e o campo userid será

automaticamente inserido pela aplicação. Se não houver validação dos dados, o

usuário pode ser capaz de comentar a tag <userid> adicionada automaticamente

pela aplicação e então especificar um userid arbitrário. Como exemplo, veja as

entradas abaixo:

Username: tony

Password: Un6R34kb!e</password><!--

E-mail: --><userid>0</userid><mail>[email protected]

Page 26: 6 TESTESDESEGURANÇAEMAPLICAÇÕES WEBmauriciolyra.pro.br/site/wp-content/uploads/2015/12/03-TESTES-DE... · conhecido, e precisam ser configurados e customizados de acordo com a

79

A aplicação ao receber esses dados irá gerar a seguinte estrutura:

<user>

<username>tony</username>

<password>Un6R34kb!e</password><!--</password>

<userid>500</userid>

<mail>--><userid>0</userid><mail>[email protected]</mail>

</user>

Nesse caso, foi possível comentar as tags <userid>. O valor do <userid> foi

alterado para 0, que pode ser o identificador do usuário administrador da aplicação.

Com esta estrutura, o usuário tony ao logar-se terá privilégios de administrador.

O teste para checar tal vulnerabilidade consiste em inserir metacaracteres

XML. Alguns exemplos de metacaracteres são: (1) aspa simples; (2) aspa duplas;

(3) caracteres < e >; (4) tags de comentários (<!- e ->); (5) caracter &; (6) tags

CDATA. Estes metacaracteres podem ser usados para tentar invalidar a estrutura do

arquivo XML e de acordo com as mensagens de erro, reunir algumas informações

sobre o a estrutura do arquivo XML usado pela aplicação.

6.7.5 SSI Injection

Server-Side Includes (SSI) são diretivas que o servidor Web interpreta antes

de enviar a página requisitada pelo usuário. As implementações mais comuns de

SSI disponibilizam comandos para incluir arquivos externos, executar scripts CGI,

executar comandos do sistema operacional, entre outros.

Na sequência são apresentados diretivas para incluir um arquivo externo e

para executar um comando do SO:

Page 27: 6 TESTESDESEGURANÇAEMAPLICAÇÕES WEBmauriciolyra.pro.br/site/wp-content/uploads/2015/12/03-TESTES-DE... · conhecido, e precisam ser configurados e customizados de acordo com a

80

<!--#include virtual="/footer.html" -->

<!--#exec cmd="ls" -->

Como em toda situação de validação incorreta de entrada, um atacante pode for-

necer uma entrada que, posteriormente, ao ser exibida será interpretado como uma

diretiva SSI.

Com base no possíveis pontos de entrada vulneráveis, o testador deve che-

car se é possível usar os mesmos caracteres que são usados em diretivas SSI. Os

caracteres estão listados a seguir:

< ! # = / . " - > and [a-zA-Z0-9]

Posteriormente, o testador deve analisar a página onde os dados fornecidos são

exibidos. Nesta etapa será possível avaliar se a entrada foi devidamente validada

ou se esta sendo interpretada como uma diretiva SSI.

6.7.6 HTTP Response Splitting

O ataque conhecido como HTTP response splitting, reune a falta de validação

da entrada do usuário mais o uso desta entrada para compor algum cabeçalho da

resposta HTTP do servidor. A falta de validação permite que um atacante envie os

caracteres CR e LF para a aplicação e, quando a aplicação fizer uso da entrada, tais

caracteres serão interpretados como caracteres de separação de linhas da resposta

HTTP.

Como exemplo, suponha uma aplicação que permita o usuário escolher entre

interface simples e interface avançada. Após escolher, o usuário irá enviar a re-

quisição para o servidor, informando que quer usar a interface avançada. Assim

Page 28: 6 TESTESDESEGURANÇAEMAPLICAÇÕES WEBmauriciolyra.pro.br/site/wp-content/uploads/2015/12/03-TESTES-DE... · conhecido, e precisam ser configurados e customizados de acordo com a

81

que a aplicação recebe a escolha do usuário, ela irá responder com uma mensa-

gem HTTP usando um cabeçalho que o redirecione para a interface avançada. A

resposta poderia ser:

HTTP/1.1 302 Moved Temporarily

Date: Sun, 03 Dec 2005 16:22:19 GMT

Location: http://aplicacao.com.br/index.php?interface=avancada

É possível notar que a aplicação faz uso da entrada do usuário para compor

o cabeçalho Location, que realiza o redirecionamento. Se a entrada não for vali-

dada, o usuário pode inserir os caracteres CR e LF, dividindo a resposta do servidor

em duas respostas HTTP. O usuário poderia então enviar o seguinte valor no parâ-

metro interface:

avancada%0d%0a<composição de outra mensagem HTTP>

Esta outra mensagem HTTP pode ser usada para montar outros ataques, tais

como Cross-Site Scripting (XSS), envenenamento de cache ou roubo de páginas

com informações sensíveis. Mais mais detalhes sobre este ataque podem ser en-

contrados em (KLEIN, 2004).

6.8 Avaliação da negação de serviço

O ataque de negação de serviço (DoS) é usado para tornar um servidor inaces-

sível. Em relação às aplicações Web pode ser possível tornar páginas e funciona-

lidades inacessíveis. Como exemplo, um usuário malicioso pode bloquear a conta

de um usuário em uma aplicação após diversas tentativas de acesso.

Page 29: 6 TESTESDESEGURANÇAEMAPLICAÇÕES WEBmauriciolyra.pro.br/site/wp-content/uploads/2015/12/03-TESTES-DE... · conhecido, e precisam ser configurados e customizados de acordo com a

82

Esta seção tem como objetivo abordar algumas formas de negação de serviço

nas aplicações Web.

6.8.1 Avaliação do bloqueio de contas de usuários

Este teste involve o sistema de autenticação de aplicações Web. Tem como

objetivo checar se um atacante consegue bloquear uma conta de usuário válida

enviando repetidamente senhas incorretas para a aplicação.

Este mecanismo de bloqueio de contas é uma maneira bastante utilizada para

evitar descoberta de senhas usando ataques de força bruta. A ação tomada pela

aplicação é bloquear a conta após um certo número de tentativas erradas. Desta

forma, mesmo se o usuário legítimo da conta fornecer as credenciais corretas,

será impossível autenticar-se até que a mesma seja desbloqueada. Assim, este

mecanismo pode ser transformado em um ataque de negação de serviço.

O testador então deve checar se de fato a aplicação bloqueia contas após um

número de tentativas erradas. Com um login válido é preciso enviar diversas se-

nhas erradas para ser possível avaliar a situação.

Na Subseção 6.4.2, foi apresentado que aplicações Web podem ser vulneráveis

a enumeração de usuários. Se um atacante obter um conjunto grande de usuário

válidos, pode-se realizar o bloqueio de diversas contas automatizando a operação

de envio de senhas erradas. Isto amplia os danos do ataque à aplicação Web.

6.8.2 Registro de dados do usuário no disco

O objetivo deste ataque é fazer com que a aplicação Web registre um log com

grande quantidade de dados. Isto pode acontecer de duas maneiras:

Page 30: 6 TESTESDESEGURANÇAEMAPLICAÇÕES WEBmauriciolyra.pro.br/site/wp-content/uploads/2015/12/03-TESTES-DE... · conhecido, e precisam ser configurados e customizados de acordo com a

83

• o testador envia uma requisição extremamente longa e a aplicação registra

em log o valor diretamente sem checar seu tamanho;

• a aplicação valida os dados, porém registra-os de forma direta afim de man-

ter os dados na forma na qual foi enviado para passar por um processo de

auditoria ou similar;

Se uma determinada aplicação Web não aplica um limite máximo para cada

entrada no log, então tal aplicação é vulnerável a este tipo de ataque.

A menos que o testador tenha acesso aos logs da aplicação e informações

sobre os discos do servidor Web, é bastante difícil comprovar o sucesso ou não do

ataque.

6.9 Teste de gerenciamento de configuração

Avaliar a infraestrutura na qual se encontra uma aplicação Web pode reve-

lar muito sobre ela. Nesta seção, o foco dos testes é checar a configuração do

transporte seguro, avaliar a infraestrutura da aplicação, avaliar o tratamento das

extensões de arquivos, entre outros.

6.9.1 Testando SSL/TLS

O transporte seguro de dados é possível com o uso de SSL/TLS, o que resulta

em tráfego HTTPS. Para garantir a segurança existe a necessidade de avaliar as

configurações do SSL.

O primeiro passo do testador é obter as portas associadas a serviços SSL/TLS.

A porta padrão é a 443, porém podem existir outras portas relacionadas. Esta

Page 31: 6 TESTESDESEGURANÇAEMAPLICAÇÕES WEBmauriciolyra.pro.br/site/wp-content/uploads/2015/12/03-TESTES-DE... · conhecido, e precisam ser configurados e customizados de acordo com a

84

verificação pode ser feita usado scanners de vulnerabilidades, tais como Nessus e

NMAP. O passo seguinte é avaliar as seguintes questões:

• a autoridade certificadora é confiável?

• o certificado é válido?

• o nome do site e o nome apresentado no certificado são os mesmos?

Geralmente os navegadores Web emitem alerta ao depararem-se com as situa-

ções descritas acima. A vantagem dos scanners é que pode-ser usado plugins para

checar tais situações e também detectar métodos fracos de criptografias, certifica-

dos vencidos ou que irão vencer nos próximos dias.

6.9.2 Avaliação da infraestrutura

Uma infraestrutura de servidores Web pode abrigar um grande número de apli-

cações Web. O gerenciamento de configuração é um passo fundamental no teste e

implantação de aplicações. Se feito adequadamente ajuda a preservar a segurança

das aplicações, pois se os elementos da infraestrutura não são devidamente con-

figurados, novos riscos e novas vulnerabilidades podem surgir e comprometer as

diversas aplicações.

A arquitetura da aplicação precisa ser revisada através de testes para determi-

nar quais diferentes componentes são usados para implementar a aplicação Web.

Pequenas configurações, como exemplo aplicações baseadas em CGI, podem usar

um único servidor para executar o software do servidor Web. Configurações mais

complexas, aplicações bancárias por exemplo, podem contar com diferentes servi-

Page 32: 6 TESTESDESEGURANÇAEMAPLICAÇÕES WEBmauriciolyra.pro.br/site/wp-content/uploads/2015/12/03-TESTES-DE... · conhecido, e precisam ser configurados e customizados de acordo com a

85

dores, um para cada função, tais como servidor de aplicação, servidor de banco de

dados, servidor LDAP, entre outros.

Para testar o gerenciamento de configuração da infraestrutura, o testador pre-

cisa avaliar os elementos da infraestrutura e as ferramentas administrativas bus-

cando vulnerabilidades conhecidas e também manter um controle sobre as portas

que são usadas pela aplicação.

A análise da infraestrutura é mais efetiva quando o testador possui informa-

ções internas do conjunto de aplicativos usados. Informações tais como versões

usadas, correções aplicadas, entre outras. Desta forma é possível verificar dire-

tamente com os fornecedores quais tipos de vulnerabilidades estão presentes em

determinado elemento, sendo possível avaliar como tal falha pode afetar as aplica-

ções da infraestrutura.

6.9.3 Testando o tratamento de extensões de arquivos

Determinar como o servidor Web lida com diferentes extensões de arquivos

ajuda a descobrir quais tipos de arquivos serão executados e quais tipos serão re-

tornados como texto puro. Um exemplo de extensão de arquivo que não é reco-

mendado usar são aqueles com extensão .inc. Ao serem requisitados, o servidor

irá retornar seu conteúdo como texto puro. O problema é que tais arquivos podem

conter informações sensíveis sobre a aplicação.

O site http://filext.com/ possui um banco de dados de extensões de ar-

quivos. Ele pode ser usado para obter mais informações sobre os diferentes tipos

de extensões.

Page 33: 6 TESTESDESEGURANÇAEMAPLICAÇÕES WEBmauriciolyra.pro.br/site/wp-content/uploads/2015/12/03-TESTES-DE... · conhecido, e precisam ser configurados e customizados de acordo com a

86

6.9.4 Arquivos sem referência, antigos e de backups

Um valiosa fonte de vulnerabilidades encontra-se em arquivos antigos e de

backups. Tais arquivos não possuem vínculo com a aplicação em produção e ge-

ralmente são esquecidos em diretórios que podem ser acessados pela Web. De

forma geral, eles aparecem nas seguintes situações:

• após edições feitas diretamente no servidor, pois os editores costumam sal-

var arquivos de backup, arquivo index.php∼ no editor Kate por exemplo;

• após cópias manuais de segurança, arquivo index.php.old por exemplo;

• após backups compactados de toda a aplicação;

• ou por simplesmente deixar arquivos que não mais fazem parte da aplicação;

Todos eles podem conter informações internas sobre a aplicação, fornecendo

credênciais e localizações de interfaces administrativas. No caso dos backups com-

pactados, caso descoberto, todo código fonte da aplicação pode ser visualizado.

O teste para a descoberta de arquivos deste tipo envolve a análise do có-

digo fonte HTML e JavaScript. Ambos podem conter comentários sugerindo

localizações de arquivos e funcionalidades escondidas na aplicação. O arquivo

robots.txt, que provê instruções aos indexadores de conteúdo, também pode

sugerir diretórios. Por fim pode-se tentar listar os diretórios do servidor Web direta-

mente pelo navegador, se o servidor não contar com uma configuração apropriada,

será possível listar seus diretórios.

Page 34: 6 TESTESDESEGURANÇAEMAPLICAÇÕES WEBmauriciolyra.pro.br/site/wp-content/uploads/2015/12/03-TESTES-DE... · conhecido, e precisam ser configurados e customizados de acordo com a

87

6.9.5 Testando os métodos HTTP

Os métodos do protocolo HTTP são usados para realizar ações no servidor

Web. Os mais comuns são os métodos GET e POST, que são usados para acessar

informações. Além destes métodos, existem outros tais como: (1) HEAD; (2) PUT;

(3) DELETE; (4) TRACE; (5) OPTIONS; (6) CONNECT.

Recomendações de segurança apontam que os seguintes métodos devem ser

desabilitados:

PUT: Permite que o usuário envie arquivos ao servidor. Pode ser explorado para

enviar arquivos maliciosos.

DELETE: Permite que o usuário apague arquivos no servidor. Pode ser usado para

desfigurar páginas.

CONNECT: Fornece a possibilidade para o usuário usar o servidor Web como um

proxy.

TRACE: Retorna ao cliente qualquer conteúdo que foi enviado ao servidor. Pode

ser usado para montar o ataque Cross Site Tracing (XST). Mais detalhes em

(GROSSMAN, 2003).

A maneira mais direta e efetiva para descobrir quais métodos HTTP estão

habilitados no servidor Web é usar o método OPTIONS. Tal método retorna uma

lista de métodos que são suportados pelo servidor. A partir desta lista o testador

pode verificar a situação dos métodos citados acima.

Page 35: 6 TESTESDESEGURANÇAEMAPLICAÇÕES WEBmauriciolyra.pro.br/site/wp-content/uploads/2015/12/03-TESTES-DE... · conhecido, e precisam ser configurados e customizados de acordo com a

88

6.10 Teste do gerenciamento de sessão

As sessões são usadas principalmente para manter um estado sobre as ações

realizadas pelos usuários nas aplicações Web. Além disso elas aumentam a faci-

lidade de uso da aplicação. Após autenticação, por exemplo, dados comprovando

a autenticidade e validade do usuário são armazenados em sessões, tais como

cookies, e são verificados a cada requisição HTTP durante o uso. Desta forma

não existe a necessidade de autenticar-se a cada página requisitada.

Esta seção tem como objetivo testar o uso de sessões em aplicações Web e

avaliar o quão seguro é o seu uso.

6.10.1 Avaliação do esquema de gerenciamento de sessões

As informações armazenas nos cookies, usados para implementar as sessões,

são de grande importância para o processo de segurança da aplicação. Se tais

informações puderem ser alteradas, pode ser possível roubar sessões de usuário,

ganhar privilégios de administração, entre outros. Assim este teste visa entender

o mecanismo de gerenciamento de sessões e verificar se os cookies resistem as

diferentes maneiras de burlagem. Os passos básicos para avaliar a segurança dos

cookies são:

Coleta: é a obtenção de vários cookies para análise.

Engenharia reversa: consiste em entender como os valores dos cookies são ge-

rados.

Manipulação: consiste em tornar um cookie válido na aplicação afim de ganhar

privilégios.

Page 36: 6 TESTESDESEGURANÇAEMAPLICAÇÕES WEBmauriciolyra.pro.br/site/wp-content/uploads/2015/12/03-TESTES-DE... · conhecido, e precisam ser configurados e customizados de acordo com a

89

Em relação ao uso de sessões, as seguintes características são desejáveis para

manter o esquema seguro: (1) imprevisibilidade; (2) resistência a alterações; (3) va-

lidade; (4) atributo secure. O testador então avalia cada característica para verificar

se o esquema provê a segurança necessária.

Testar a imprevisibilidade significa, avaliar vários cookies e tentar prever ou-

tros. Em outras palavras, buscar padrões para gerar outros cookies.

Testar a resistência a alterações significa avaliar se a aplicação executa uma

checagem dupla no cookie. Como exemplo, além de enviar o valor do cookie

tal como admin=true, enviar também o valor true na forma de hash, assim ao

receber o valor, a aplicação verifica se o hash do valor atual do cookie combina

com o hash original. Se não combinar significa que o valor foi alterado e ele deve

ser descartado.

É desejavel também que os cookies tenha uma validade adequada e posterio-

mente seja deletado quando não mais necessario.

Por fim, o atributo secure informa ao navegador que o cookie possui informa-

ções sensíveis e que não deve ser enviado em vias descriptografadas.

6.10.2 Avaliação dos atributos dos cookies

Devido a natureza sensível das informações carregadas pelos cookies é fun-

damental tomar as devidas ações para garantir sua segurança. Os cookies possuem

diferentes atributos que podem ser usados para aumentar a segurança. Os seguintes

podem ser usados: (1) secure; (2) HttpOnly; (3) domain; (4) path; (5) expires. As-

sim, o papel do testador é avaliar se tais atributos estão sendo usados corretamente

pela aplicação.

Page 37: 6 TESTESDESEGURANÇAEMAPLICAÇÕES WEBmauriciolyra.pro.br/site/wp-content/uploads/2015/12/03-TESTES-DE... · conhecido, e precisam ser configurados e customizados de acordo com a

90

Uma descrição dos atributos e como avaliá-los é apresentada na sequência.

Secure: Este atributo limita o uso dos cookies somente quando houver transmis-

são criptografada, HTTPS por exemplo.

HttpOnly: O uso deste atributo não é reconhecido em todos os navegadores, po-

rém é desejável ser usado pois limita o uso dos cookies apenas ao protocolo

HTTP, ou seja, impede que os cookies sejam manipulados por scripts no

lado cliente, via JavaScript por exemplo. Desta forma o roubo de sessão

feito com XSS é dificultado.

Domain: Este atributo limita o uso dos cookies somente ao domínio especificado.

É preciso avaliar se o atributo domain não foi configurado vagamente. Como

exemplo, se o cookie é necessário apenas no domínio app.site.com, o

atributo deve ser setado especificamente a este domínio, privando outros

como outro_app.site.com de recebé-lo.

Path: Tal como o atributo domain, este também deve ser setado de forma espe-

cífica. Se a aplicação encontra-se em app.site.com/versao2, o atributo

path deve ser setado como path="/versao2/", com a barra no final para

evitar que versao2-vulneravel também seja aceito.

Expires: Se o tempo para expiração do cookie for definido com datas futuras, e

não com o fechamento do navegador, é preciso avaliar se tal cookie não

carrega informações sensíveis.

A ferramenta WebScarab da OWASP e o plugin FireCookie do navegador Web

Firefox podem ser usados para avaliar os cookies e seus atributos.

Page 38: 6 TESTESDESEGURANÇAEMAPLICAÇÕES WEBmauriciolyra.pro.br/site/wp-content/uploads/2015/12/03-TESTES-DE... · conhecido, e precisam ser configurados e customizados de acordo com a

91

6.10.3 Avaliação de session fixation

Session fixation é um método de obter um identificador válido de sessão. Tal

vulnerabilidade pode ocorrer em aplicações que não renovam a sessão após um

processo de autenticação com sucesso. De forma geral a vulnerabilidade associada

a session fixation funciona da seguinte forma:

• atacante cria um nova sessão na aplicação;

• o atacante faz com que a vítima acesse a aplicação usando o mesmo identi-

ficador de sessão criado por ele anteriormente;

Como já mencionado, se a aplicação não renova a sessão do usuário após a

autenticação, tal aplicação pode ser vulnerável a session fixation. Usando o iden-

tificador de sessão criado pelo atacante, ele tenta convencer a vítima a acessar al-

guma página que altere a sessão do usuário para aquela sessão conhecida por ele.

Se feito com sucesso, a sessão que é conhecida pelo atacante será associada ao

usuário real da aplicação. Após autenticação na aplicação, os privilégios do usuá-

rio real serão associados a sessão criada pelo atacante, concedendo os privilégios

também ao atacante, pois ele tem acesso ao cookie.

Mais detalhes sobre este vasto assunto pode ser encontrado em (SHIFLETT,

2004).

6.10.4 Avaliação CSRF

Cross Site Request Forgery (CSRF, pronuncia-se “sea surf ”) é um tipo de

ataque que aproveita a identidade e privilégios da vítima para executar ações não

Page 39: 6 TESTESDESEGURANÇAEMAPLICAÇÕES WEBmauriciolyra.pro.br/site/wp-content/uploads/2015/12/03-TESTES-DE... · conhecido, e precisam ser configurados e customizados de acordo com a

92

desejadas na aplicação Web na qual ela esta autenticada. Isto é feito após a vítima

carregar uma página que contém uma requisição maliciosa. No ponto de vista da

aplicação a ação foi realizada pelo próprio usuário, no ponto de vista do atacante,

o usuário executou a ação sem saber, pois desconhecia que tal página tinha uma

ação maliciosa.

Como já abordado anteriormente, as aplicações Web geralmente fazem o uso

de sessões para manter informações sobre o usuário e também informações sobre

as credênciais de autenticação. Esses dados de sessão são automaticamente envi-

ados ao servidor da aplicação, enquanto o usuário a usa, a cada requisição feita.

Assim o usuário pode acessar diversos sites, quando a aplicação na qual ele está

autenticado for usada, os dados de sessão, anteriormente definidos, serão também

enviados.

O ataque CSRF inicia quando um atacante consegue obter links válidos da

aplicação, ou seja, links que ao serem acessados realizam algum tipo de ação na

aplicação. O atacante então convence a vítima a acessar tal link ou envia o link de

uma página por ele trabalhada que executa a requisição maliciosa. Isto pode ser

feito usando a tag img e colocando o link da ação malicosa no atributo src, tal

como:

<img src="http://aplicacao.com/deletar_usuarios.php" width="0" height="0" />

Tal página preparada pelo atacante contém um link válido da aplicação Web e

ele executa a ação de deletar usuários. A vítima ao acessar esta página irá carregar

também o link http://aplicacao.com/deletar_usuarios.php executando a

ação de deletar usuários. O fato é que o usuário deve estar logado na aplicação,

pois ao executar tal link o navegador da vítima automaticamente irá enviar tam-

bém os dados de sessão dela. Desta forma a ação será executada com sucesso

aproveitando-se da identidade e privilégios do usuário na aplicação.

Page 40: 6 TESTESDESEGURANÇAEMAPLICAÇÕES WEBmauriciolyra.pro.br/site/wp-content/uploads/2015/12/03-TESTES-DE... · conhecido, e precisam ser configurados e customizados de acordo com a

93

Entre as ações que podem ser tomadas para proteger uma aplicação de tal

vulnerabilidade é o uso de informações de sessão a nível do URL. Isto tornará o

trabalho do atacante mais complexo, pois com as informações de sessão será mais

complicado para ele conhecer a estrutura dos links válidos na aplicação. Outra

ação é o uso de janelas popup para a confirmação destas ações.

Para o teste, o testador deve possuir links válidos da área que necessita de

autenticação para acesso. Se o testador possuir credênciais válidas, ele irá assumir

o papel de atacante e vítima, ao mesmo tempo, para avaliar se a aplicação permite

tal ataque.

Mais detalhes sobre o ataque CSRF podem ser encontrados em (WATKINS,

2001).

6.11 Avaliação da técnica Ajax

Como abordado no Seção 2.5, Ajax é uma técnica que agrupa diversas tec-

nologias para enviar requisições assíncronas ao servidor e trabalhar a resposta do

mesmo. De forma geral, as vulnerabilidades usando Ajax são semelhantes as re-

quisições comuns, sem uso de Ajax. Assim a maioria dos testes, extensivamente

apresentados, são aplicáveis, pois o que muda é a forma da requisição de síncrona

para assíncrona.

O teste consiste em identificar os destinos das requisições HTTP assíncronas

e então analisá-los em busca de vulnerabilidades, tais como: alteração de parâme-

tros, SQL Injection, entre outras. A identificação dos destinos das requisições pode

ser através da análise do código fonte HTML e JavaScript. Outra forma é usar usar

um proxy para interceptá-las. Com os pontos de destinos o testador pode avaliar o

formato das requisições.

Page 41: 6 TESTESDESEGURANÇAEMAPLICAÇÕES WEBmauriciolyra.pro.br/site/wp-content/uploads/2015/12/03-TESTES-DE... · conhecido, e precisam ser configurados e customizados de acordo com a

94

O plugin FireBug39 do navegador Web Firefox pode ser usado para testar o uso

de Ajax pela aplicação Web. É possível facilmente identificar os destinos das re-

quisições feitas através do objeto XmlHttpRequest e também identificar a estrutura

dos dados enviados. Mais detalhes sobre o uso do navegador Firefox para explo-

rar aplicações Web que usam a técnica Ajax podem ser encontrados em (SHAH,

2006). E maiores informações sobre os perigos que surgem com o uso de Ajax

podem ser encontrados em (HOFFMAN, 2006).

6.12 Avaliação de web services

De acordo com (HAAS, 2004), web service é um sistema modelado para ser

usado entre diferentes máquinas através da rede. A interface do serviço é descrita

no arquivo WSDL (Web Services Description Language), informações de como

acessá-lo, operações suportadas, formato das entradas, entre outras, são especi-

ficadas nele. A interação entre as máquinas é feita através de mensagens SOAP

(Simple Object Access Protocol). Tal protocolo especifica como deve ser feita a

troca de informações entre eles.

As vulnerabilidades em web services são similares as vulnerabilidades já des-

critas extensivamente neste capítulo, tais como SQL Injection e vazamento de in-

formações, porém os web services podem também ter vulnerabilidades relaciona-

das ao parser das mensagens SOAP.

Esta seção abordará os testes que podem ser feitos em web services.

39https://addons.mozilla.org/pt-br/firefox/addon/firebug/

Page 42: 6 TESTESDESEGURANÇAEMAPLICAÇÕES WEBmauriciolyra.pro.br/site/wp-content/uploads/2015/12/03-TESTES-DE... · conhecido, e precisam ser configurados e customizados de acordo com a

95

6.12.1 Avaliação do WSDL

A partir do arquivo WSDL, aquele que descreve o web service, o testador pode

identificar os métodos e tipos de dados esperado pelo web service. Desta forma,

é necessário avaliar se é possível invocar operações não permitidas e se existem

métodos que retornam informações sensíveis.

Um situação possível de ser encontrada é a existência de uma interface Web

para invocar um web service. Tal inteface pode mostrar apenas algumas opera-

ções, porém se o WSDL for checado, o testador pode encontrar outras operações

não listadas na interface. Usando o WebScarab por exemplo, é possível alterar a

requisição SOAP e invocar o método que a interface Web não listou.

6.12.2 Avaliação da estrutura do XML

A forma de comunicação entre o web service e o cliente é feita usando a

estrutura de arquivos XML. Assim tais arquivos devem estar bem formados para

que o web service funcione adequadamente, caso contrário o parser XML do web

service pode falhar.

Os ataques envolvendo XML envolvem requisições SOAP com a estrutura

errada e com tamanhos acima do normal. A função do testador então é interagir

com o web service enviando requisições mal formadas e com tamanho grande e,

consequentemente, observar o comportamento do web service.

Page 43: 6 TESTESDESEGURANÇAEMAPLICAÇÕES WEBmauriciolyra.pro.br/site/wp-content/uploads/2015/12/03-TESTES-DE... · conhecido, e precisam ser configurados e customizados de acordo com a

96

6.12.3 Avaliação do conteúdo do XML

Através da requisição SOAP, o cliente realiza chamadas de funções e espe-

cifica parâmetros para a realização de alguma tarefa no web service. Este teste

consiste em avaliar os parâmetros enviados. O mais comum é a injeção de códigos

SQL.

Como exemplo, considere um web service que obrigue o usuário a autenticar-

se. Se as credênciais (login e senha) enviadas pelo usuário não forem validadas,

ele será capaz de usar o web service com privilégio de usuário autenticado. Isto

pode ser possível ao enviar parâmetros que tornam a condição de autenticação

sempre verdadeira, ou seja, fazendo uso de SQL Injection, como já abordade ante-

riormente.

6.13 Comentários finais

Neste capítulo, foi apresentado uma idéia dos testes que podem ser realizados

em aplicações Web. Para uma versão mais aprofundada das abordagens apresen-

tadas é aconselhável consultar OWASP Testing Guide Versão 3 (MEUCCI, 2008).

Vale notar que o capítulo em toda sua extensão tomou como base o guia acima

citado.

No próximo capítulo, aplicações reais serão colocadas em prova usando a

metodologia de testes de aplicações Web da OWASP.