O documento discute os 10 principais riscos de segurança da web segundo a OWASP de 2013. São eles: 1) Injeção, 2) Autenticação/sessão incorreta, 3) Cross-site scripting (XSS), 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, 8) Cross-site request forgery (CSRF), 9) Uso de componentes com falhas conhecidas e 10) Redirects e forwards não validados. Para

1. Segurança Web
OWASP 2013 – TOP 10

3. ;10) Redirects e Forwards não validados

4. • 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?

5. 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

6. 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

7. ;
9) Usar componentes com falhas de segurança
conhecidas

8. 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?

9. 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?

10. ;8) CSRF (Cross-Site Request Forgery)

11. 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

12. Exemplos...
8) CSRF

13. 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

14. ;
7) Falta de verificação de acesso em
funcionalidades

15. 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

16. 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

17. 6) Exposição de dados confidenciais

18. 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

19. ;
5) Configuração incorreta de segurança

20. 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

21. ;
4) Referências diretas não protegidas

22. Exemplos:
http://www.meusite.com/compras/detalhe?idCompra=1234
4) Referências diretas não protegidas

23. 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?

24. http://marcoagner.com/posts/ingresso.com-como-nao-lidar-com-
seguranca-da-info/
4) Referências diretas não protegidas
Outro exemplo:

25. ;
3) XSS (Cross-Site Scripting)

26. • 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)

27. 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?

28. ;
2) Autenticação/gerenciamento de
sessão incorreto

29. • 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

30. Exemplos...
2) Autenticação/gerenciamento de sessão
incorreto

31. 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)

33. ;
1) Injection

35. 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

36. ;
0) Heart Bleed
"Catastrophic is the right word. On the scale of 1 to
10, this is an 11."

37. Application Security Verification Standard
ASVSASVS

38. 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/