OWASP TOP 10 - Web Security

542 views
409 views

Published on

Slides of the presentation about web security I gave at CWI.
The slides are in portuguese.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
542
On SlideShare
0
From Embeds
0
Number of Embeds
15
Actions
Shares
0
Downloads
14
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

OWASP TOP 10 - Web Security

  1. 1. Segurança Web OWASP 2013 – TOP 10
  2. 2. ;10) Redirects e Forwards não validados
  3. 3. • Aplicações web geralmente usam redirects e forwards para enviar usuários para outras páginas/sites. Sem a validação necessária, agressores podem redirecionar as vítimas para sites maliciosos OU utilizar forwards para acessar páginas não autorizadas. 10) Redirects e Forwards não validados Como funciona?
  4. 4. Exemplos: 1) http://www.meusite.com/redirect.jsp?url=virus.com 2) http://www.meusite.com/redirect.jsp?fwd=admin 10) Redirects e Forwards não validados
  5. 5. Como evitar? 1) Evite forwards e redirects 2) Caso realmente sejam necessários, não utilize parâmetros do usuário para “definir” o destino; 3) Se os parâmetros não podem ser evitados (geralmente podem) verifique que o valor informado é válido para o usuário (whitelist) 10) Redirects e Forwards não validados
  6. 6. ; 9) Usar componentes com falhas de segurança conhecidas
  7. 7. Bibliotecas vulneráveis podem ser exploradas por usuários maliciosos. O impacto de falhas de segurança em bibliotecas/componentes pode variar bastante. 9) Usar bibliotecas com falhas de segurança conhecidas Como funciona?
  8. 8. 1) É difícil. 2) Não usar nenhuma biblioteca? 3) Verificar o site/bugzilla/changelog/issues das bibliotecas que estão sendo utilizadas, incluindo as dependências; 4) Manter as bibliotecas atualizadas 9) Usar bibliotecas com falhas de segurança conhecidas Como evitar?
  9. 9. ;8) CSRF (Cross-Site Request Forgery)
  10. 10. Como funciona? 1) Usuário se autentica normalmente no site exemplo.com.br 2) Sem efetuar logout, o usuário visita o site virus.com.br, que faz uma requisição maliciosa para o site exemplo.com.br 3) Como o usuário ainda está autenticado, caso o site exemplo.com.br não esteja protegido, a requisição funcionará normalmente. 8) CSRF
  11. 11. Exemplos... 8) CSRF
  12. 12. Como evitar? 1) Evitar CSRF geralmente implica em criar uma token em cada requisição HTTP. Essa token dever única e mudar, no mínimo, a cada nova sessão. 2) A token também pode ser incluída na URL (através da query string, mas isso é menos seguro) 3) CAPTCHAs também ajudam a proteger contra CSRF. 8) CSRF
  13. 13. ; 7) Falta de verificação de acesso em funcionalidades
  14. 14. Como funciona? • Um usuário malicioso simplesmente muda a URL ou muda um parâmetro e acessa uma funcionalidade do sistema que deveria estar bloqueada. 7) Falta de verificação de acesso em funcionalidades
  15. 15. Como evitar? 1) O mecanismo de autorização deve, por padrão, negar acesso a uma funcionalidade e só permitir acesso caso o usuário possua a permissão explicitamente definida 2) A maior parte das aplicações não exibem links e botões para telas/rotinas bloqueadas, mas essa validação também deve ser efetuada no Controller ou na lógica de negócio 7) Falta de verificação de acesso em funcionalidades
  16. 16. 6) Exposição de dados confidenciais
  17. 17. 1) Existe algum dado confidencial (ex.: senhas, número de cartões de crédito) armazenado em texto? 2) A conexão está usando HTTP (ao invés de HTTPS) para transmitir dados confidenciais? 6) Exposição de dados confidenciais
  18. 18. ; 5) Configuração incorreta de segurança
  19. 19. Exemplos: 1) Existem recursos desnecessários habilitados ou instalados (ex. portas, serviços, páginas, contas, privilégios)? 2) Os usuários e senhas padrão foram alterados? 3) No caso de erros no sistema, o stack trace é exibido para os usuários (ou qualquer outra informação excessiva)? 4) As configurações padrão de segurança nos frameworks de desenvolvimento (ASP.NET, Spring, Struts) foram alteradas? 5) Configuração incorreta de segurança
  20. 20. ; 4) Referências diretas não protegidas
  21. 21. Exemplos: http://www.meusite.com/compras/detalhe?idCompra=1234 4) Referências diretas não protegidas
  22. 22. 1) Valide o acesso antes de exibir o conteúdo 2) Não utilize referências diretas. Crie referências indiretas que são válidas somente para um usuário ou sessão (map) 4) Referências diretas não protegidas Como evitar?
  23. 23. http://marcoagner.com/posts/ingresso.com-como-nao-lidar-com- seguranca-da-info/ 4) Referências diretas não protegidas Outro exemplo:
  24. 24. ; 3) XSS (Cross-Site Scripting)
  25. 25. • Um usuário malicioso envia texto contendo scripts que serão interpretados pelo browser • Praticamente qualquer fonte de dados pode ser a origem da injeção de scripts: campos de texto, URL, banco de dados • O impacto da injeção de script inclui: roubar sessão, modificar sites (phising), redirecionar usuários, forçar download de arquivos, etc. 3) XSS (Cross-Site Scripting)
  26. 26. 1) Nunca confiar em dados fornecidos pelo usuário 2) Fazer escape dos caraceteres que serão exibidos na página/script/url 3) Content-Security-Policy header 4) https://www.owasp.org/index.php/XSS_Filter_Evasion_C heat_Sheet 3) XSS (Cross-Site Scripting) Como evitar?
  27. 27. ; 2) Autenticação/gerenciamento de sessão incorreto
  28. 28. • Autenticação e gerenciamento de sessão é difícil de implementar corretamente; • As aplicações normalmente possuem falhas que permitem usuários maliciosos obter senhas, logins, tokens de sessão ou explorar outras falhas para utilizar a identidade de outro usuário 2) Autenticação/gerenciamento de sessão incorreto
  29. 29. Exemplos... 2) Autenticação/gerenciamento de sessão incorreto
  30. 30. 2) Autenticação/gerenciamento de sessão incorreto 1) Senhas não são criptografadas durante o armazenamento 2) Credenciais podem ser adivinhadas, recuperadas ou alteradas através de funções como “esqueci minha senha”, “mudar senha”, etc; 3) Sessions Ids são expostos na URL (URL rewriting) 4) Session ids são vulneráveis a “Session Fixation” 5) Sessão não é invalidada durante o logout ou nunca expira 6) Senhas/session ids são enviados sem criptografia em conexões não criptografadas (ex.: HTTP)
  31. 31. ; 1) Injection
  32. 32. RECAPITULANDO... 1) Injection 2) Autenticação/gerenciamento de sessão incorreto 3) XSS (Cross-Site Scripting) 4) Referências diretas não protegidas 5) Configuração incorreta de segurança 6) Exposição de dados confidenciais 7) Falta de verificação de acesso em funcionalidades 8) CSRF (Cross-Site Request Forgery) 9) Usar componentes com falhas de segurança conhecidas 10) Redirects e forwards não validados
  33. 33. ; 0) Heart Bleed "Catastrophic is the right word. On the scale of 1 to 10, this is an 11."
  34. 34. Application Security Verification Standard ASVSASVS
  35. 35. Referências o https://www.owasp.org o https://www.owasp.org/index.php/Category:OWASP_App lication_Security_Verification_Standard_Project o http://docs.spring.io/spring- security/site/docs/3.2.x/reference/htmlsingle/#csrf o https://freedom-to-tinker.com/blog/wzeller/popular- websites-vulnerable-cross-site-request-forgery-attacks/

×