Testes de segurança em aplicações web são importantes devido ao aumento de incidentes de segurança. As principais falhas incluem injeção de código, cross-site scripting e falhas na autenticação. Ferramentas open source como WebScarab e WebGoat podem ser usadas para mapear aplicações e testar vulnerabilidades comuns.
4. Introdução
No início da internet, segurança não era
preocupação.
Hoje a maoria dos sites é uma aplicação
Possuem muitas funcionalidades.
Suportam login, transações comerciais.
Conteúdo dinâmico.
Informações confidenciais.
5. Introdução
Cada aplicação é diferente.
Falhas únicas.
Desenvolvidas por pessoas que possuem
pouco entendimento sobre segurança.
Sites consultam servidores que possuem
informações confidenciais.
SSL
Não impossibilita ataques.
Segurança ruim pode comprometer bolso.
6. Introdução
Segurança na transmissão de dados é
importante.
Comércio eletrônico.
Tráfego de informações confidenciais.
Evitar fraudes.
Evitar propagação de virus
8. Por que fazer testes de segurança?
Apesar do aumento da preocupação,
incidentes vêm aumentando ano a ano.
Aumento de incidentes de 61% de 2008 para
2009.
Aumento de 11530% de 1999 até 2009.
Universidade de Michigan -> 75% dos sites de
Bancos possuem alguma falha grave.
Whitehat Security -> 64% de 1364 sites
corporativos possuem falhas graves.
9. Problema principal da segurança
O Usuário pode enviar QUALQUER dado
Deve-se assumir que toda entrada pode ser
maliciosa.
Requisições podem ser feitas em qualquer
sequência
Usuários não irão usar apenas o navegador
para acessar a aplicação.
10. Problema principal da segurança
Exemplos:
Usuários podem mudar o preço de um produto
na requisição;
Modificar o token da sessão transmitido.
Remover certos parâmetros que normalmente
são enviados.
Armazenar Scripts para serem rodados depois.
SSL não resolve esse problema.
11. Top 10 Owasp
Falhas de injeção
Cross Site Scripting (XSS)
Falhas de autenticação e de gerenciamento de sessão
Referência insegura a objetos
Cross Site Request Forgery (CSRF)
Problemas de configuração
Falha ao rstringir o acesso a alguma URL
Redirecionamento inválido
Problemas no armazenamento de informações
confidenciais
Proteção na camada de transporte insuficiente
Sem criptografia
Certificados inválidos
12. Mapeamento da aplicação
Levantamento de informações sobre a
aplicação.
O que ela faz e como ela funciona?
Examinar cada aspecto de suas funcionalidades.
Mapeamento manual
Para processo preciso, automação é
necessária.
Ferramentas chamadas de Web Spidering
14. Cookies
Cookies
Cookies também podem ter valor alterado
Ex.:
Cookie de sessão, usuário e desconto.
15. Transmissão de dados via
parâmetros da URL
Pode ser mudado de forma trivial sem usar
qualquer ferramenta.
16. Validações do lado do cliente
Validações podem ser burladas
Significa que são inúteis?
Não
Melhora usabilidade
Diminui requisições ao servidor.
17. Atacando a Autenticação
Se usuário existe e tem permissão ele loga.
Senão, não loga.
Autenticação TEM que ser segura.
Senhas “Fracas”
Senha iniciada com um valor padrão
Login por força bruta
Logins comuns, de teste, controle de falhas
por cookies.
Senha com valor padrão.
18. Força bruta
Mensagem diferente na falha do login e da senha
Acessos com vários estágios de autenticação.
Algumas aplicações reiniciam a senha assim que
a pergunta secreta é respondida.
Dicas:
Entenda o mecanismo através de uma conta que você
conheça.
Se existe uma pergunta secreta, identifique as possíveis
perguntas.
Tente identificar qualquer comportamento que possa
ser explorado.
Funcionalidade Remember me.
19. Prevenção de ataques de força
bruta
Travamento da conta após algumas
tentativas
Suspensão da conta por algum período
Uso do captcha
Informação do captcha deve estar apenas na
imagem.
20. Testar existência de logs
Deve-se logar todas as informações que
podem vir a ser relevantes
Qualquer suspeita de anomalia deve ser
investigada.
Usuários devem ser informados de qualquer
possibilidade de vazamento de informações.
21. Atacando o controle de acesso
Acesso vertical
Usuários conseguem acessar funcionalidade
que não deveriam conseguir.
Acesso horizontal
Um usuário consegue ver ou modificar dados
que ele não deveria conseguir.
Ex: WebMail, bancos etc.
22. Exemplos de falhas
Arquivos estáticos
https://www.site.com/download/0636628104.pdf
Acesso passado via URL
https://wahh.site.com/login/home.jsp?admin=true
Path traversal
WebGoat (Bypass a Path Based Access control)
../../../conf/tomcat-users.xml
Etágio 1 de (Bypass a Path Based Access control)
23. Injetando código
Definição
Manipulação de uma instrução SQL através
das variáveis quem compõem os parâmetros
recebidos a ser inseridos numa consulta.
Objetivo do Uso
Permissão de acesso a conteúdo restrito;
Deleção de tabelas;
Alteração / Deleção / Inserção de conteúdos;
Outros.
25. Injetando código
Teste de Vulnerabilidade Básico
http://www.site.com.br/noticias.asp?publisher=wiley
http://www.site.com.br/noticias.asp?publisher=wiley’
Microsoft JET Database Engine (0x80040E14)
Erro de sintaxe na seqüência de caracteres na
expressão de consulta ‘publisher= wiley''.
/noticias.asp, line 6
26. Injetando código
Considere uma aplicação web que possua
uma tela que faça a seguinte pesquisa
SELECT author,title,year FROM books WHERE
publisher = ‘Wiley’
E se o usuário digitar no campo de pesquisa:
Wiley’ OR ‘a’ = ‘a
E se a for colocado um OR desses no login?
28. Atacando outros usuários
Ataques aos usuários
Usuários atacam a aplicação com o intuito de
atacar o usuário.
“Travamento” do usuário.
Roubo de dados.
Scripts podem “vigiar” os usuários.
Scripts podem modificar o conteúdo do site.
Explorar relação de confiança.
Travar ou redirecionar browser.
Principal forma:
Cross-site scripting.
29. Cross-site Scripting (XSS)
XSS não armazenado: código malicioso é inserido
na página e resposta é obtida instantaneamente.
https://www.site.com.br/error.php?message==Desculpe%2c+um
+erro+ocorreu
https://www.site.com.br/error.php?message=<script>alert(‘xss’);
</script>
XSS armazenado: o código malicioso é inserido no
servidor para ser executado posteriormente.
<script>alert(‘xss’);</script>
Exemplo:
Stored XSS no WebGoat – Stage 1
Banco do Brasil
30. Cross-site Scripting (XSS)
Exemplo 2
http://www.infoconsumo.gov.br/busca/busca.asp
Código da página:
<input type="TEXT" class="caixaSimples" value=""
maxlength="100" size="25" name="SearchString">
Entrada: '"><script>alert('teste')</script>
Saída:
<input type="TEXT" name="SearchString" size="25"
maxlength="100" value="'"> <script>alert(‘teste') </script> "
class="caixaSimples">
Outros exemplos de entradas
XSS-Me
SQL Inject Me
31. Ataque Cross-site Scripting ao
MySpace
Usuário Implementou script que fazia 2
coisas:
Adicionava o invasor na lista de amigos
Copiava o script no profile da vítima.
1 milhão de vítimas em menos de 1 hora.
MySpace foi retirado do ar.
Removeu o código mailicioso de todos os
profiles.
32. Explorando informações exibidas
Mensagens de erro.
Stack Traces exibidos.
Mostra a razão precisa do erro.
Faz referência a bibliotecas de terceiros.
Informações adicionais sobre o ambiente.
Erros de scripts.
Dicas sobre parâmetros.
Mensagens de depuração.
33. Revisões no código
Existem várias situações onde é possível
auditar o código.
Ex: Verificar se as entradas estão sendo
tratadas.
Programador experiente
Conhecimento profundo da arquitetura.
34. Algumas ferramentas
Plugins para navegadores
Firefox
FoxyProxy
Tamper Data
Live HTTP Headers
AddNEditCookies
Cookie Watcher
XSS Me
SQL Inject Me
Hack Bar
37. Conclusão
Todo sistema / aplicação é passível de
invasão.
Todos usuários são potenciais invasores.
Otimização e cautela na programação.
Análise de riscos.
Novas tecnologias irão criar novas “brechas”.
Ataques às aplicações estão perdendo espaço
para ataques a usuários.
38. Referências
Livros
The Web Application Hacker’s Handbook
Software Security: Building Security In
Cross-Site Scripting: Uma Análise Prática
Analyzing the Accuracy and Time Costs of
Web Application Security Scanners
http://www.parosproxy.org/index.shtml
Projeto Owasp
http://www.owasp.org
39. Testes de segurança em aplicações web
Eduardo Habib Bechelane Maia.
habib@dcc.ufmg.br