Baixar para ler offline
Carregado porGiovani Decusati
OWASP Top Ten
O documento discute as 10 principais vulnerabilidades da OWASP, incluindo injeção, quebra de autenticação, XSS e uso de componentes vulneráveis. Ele fornece exemplos e orientações sobre como evitar cada uma, como validar dados de entrada, usar tokens CSRF e manter componentes atualizados. A conclusão é que as organizações devem ir além dos top 10 e reduzir vulnerabilidades em toda a aplicação.
OWASP Top Ten
- 1. 1 S egurança WebO WAS P 2 0 1 3 - T O P 1 0
- 2.
- 3. 3 Por que sepreocupar com isso? Fonte: http://www.usnews.com/news/articles/2015/08/06/reported-russian-cyber-attack-shuts- down-pentagon-network
- 4. 4 Por que sepreocupar com isso? Fonte: http://thehackernews.com/2015/09/whatsapp-vcard-vulnerability.html
- 5. 5 Por que sepreocupar com isso? Fonte: http://money.cnn.com/2015/08/18/technology/ashley-madison-data-dump
- 6.
- 7. 7 10) Redirecionamentos eEncaminhamentos Inválidos • Aplicações web frequentemente redirecionam e encaminham usuários para outras páginas e sites, e usam dados não confiáveis para determinar as páginas de destino. Sem uma validação adequada, os atacantes podem redirecionar as vítimas para sites de phishing ou malware, ou usar encaminhamentos para acessar páginas não autorizadas. Exemplos: • http://www.example.com/redirect.jsp?url=evil.com • http://www.example.com/boring.jsp?fwd=admin.jsp
- 8. 8 10) Redirecionamentos eEncaminhamentos Inválidos Como evitar? • Evitar usar “redirects” e “forwards” • Caso sejam necessários, não utilize parâmetros para definir o destino • Se parâmetros não podem ser evitados, valide os parâmetros de redirecionamento e verifique os valores para o usuário
- 9. 9 9) Utilização deComponentes Vulneráveis Conhecidos • Componentes, bibliotecas, frameworks, e outros módulos de software quase sempre são executados com privilégios elevados. Se um componente vulnerável é explorado, um ataque pode causar sérias perdas de dados ou o comprometimento do servidor. Referências: • Common Vulnerabilities and Exposures https://cve.mitre.org/ • National Vulnerability Database https://nvd.nist.gov/home.cfm
- 10. 10 9) Utilização deComponentes Vulneráveis Conhecidos
- 11. 11 9) Utilização deComponentes Vulneráveis Conhecidos Como evitar? • É difícil. • Não usar nenhuma biblioteca? • Verificar com o fornecedor as bibliotecas que estão sendo utilizadas, incluindo as suas dependências; • Manter as bibliotecas atualizadas
- 12. 12 8) Cross-Site RequestForgery (CSRF) • Usuário se autentica normalmente no site exemplo.com.br • Sem efetuar logout, o usuário visita o site virus.com.br, que faz uma requisição maliciosa para o site exemplo.com.br • Como o usuário ainda está autenticado, caso o site exemplo.com.br não esteja protegido, a requisição funcionará normalmente
- 13. 13 8) Cross-Site RequestForgery (CSRF)
- 14. 14 8) Cross-Site RequestForgery (CSRF) Como evitar? • Evitar CSRF geralmente implica em criar uma token em cada requisição HTTP(s). Essa token dever única e mudar, nomínimo, a cada nova sessão. • O token também pode ser incluído na URL (através da query string, mas isso é menos seguro) • CAPTCHAs também ajudam a proteger contra CSRF.
- 15. 15 7) Falta deFunção para Controle do Nível de Acesso 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.
- 16. 16 7) Falta deFunção para Controle do Nível de Acesso Como evitar? • 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 • 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
- 17. 17 6) Exposição deDados Sensíveis • Como são armazenados os dados confidenciais (ex.: senhas, número de cartões de crédito)? • Os dados são trafegados por HTTPS ao invés de HTTP?
- 18. 18 6) Exposição deDados Sensíveis Fonte: Auditoria de arquitetura realizada em cliente.
- 19. 19 5) Configuração Incorretade Segurança 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?
- 20. 20 5) Configuração Incorretade Segurança
- 21. 21 4) Referência Insegurae Direta a Objetos Exemplo: • http://www.meusite.com/compras/detalhe?idCompra=1234
- 22. 22 4) Referência Insegurae Direta a Objetos Fonte: Auditoria de arquitetura realizada em cliente.
- 23. 23 3) Cross-Site Scripting(XSS) • 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.
- 24. 24 3) Cross-Site Scripting(XSS) Como evitar? • Nunca confiar em dados fornecidos pelo usuário • Fazer escape dos caraceteres que serão exibidos na página/script/url • Content-Security-Policy header • https://www.owasp.org/index.php/XSS_Filter_Evasion_Chea t_Sheet
- 25. 25 2) Quebra deAutenticação e Gerenciamento de sessão • 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
- 26. 26 2) Quebra deAutenticação e Gerenciamento de sessão 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. Sessão não é invalidada durante o logout ou nunca expira 5. Senhas/session ids são enviados sem criptografia em conexões não criptografadas (ex.: HTTP)
- 27. 27 2) Quebra deAutenticação e Gerenciamento de sessão
- 28. 28 1) Injeção • Asfalhas de Injeção, tais como injeção de SQL, de SO (Sistema Operacional) e de LDAP, ocorrem quando dados não confiáveis são enviados para um interpretador como parte de um comando ou consulta. Os dados manipulados pelo atacante podem iludir o interpretador para que este execute comandos indesejados ou permita o acesso a dados não autorizados.
- 29.
- 30. 30 1) Injeção Fonte: Auditoriade arquitetura realizada em cliente.
- 31. 31 Não pare porai • Não pare nos Top Ten! Mais de 500.000 vulnerabilidades • Organizações devem se concentrar para reduzir o número de vulnerabilidades • ASVS: Application Security Verification Standard • OWASP ZAP • HP Tools • Fortify • WebInspect • Free • http://sqlmap.org/ • http://www.metasploit.com/ • https://portswigger.net/burp/ • http://www.backtrack-linux.org/ • https://www.kali.org/
- 32. 32 Referências • https://www.owasp.org • https://www.owasp.org/index.php/Category:OWASP_Applicat ion_Security_Verification_Standard_Project •https://freedom-to-tinker.com/blog/wzeller/popularwebsites- vulnerable-cross-site-request-forgery-attacks • https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat _Sheet
- 33.
Notas do Editor
- #3 OWASP Foundation é uma organização internacional formada por uma comunidade aberta disposta a criar, desenvolver, operar, adquirir e manter aplicações Web confiáveis. Foi fundada em 2001 nos EUA, tornou-se sem fins lucrativos em 21 de Abril de 2004, mantendo o foco em gerar documentos e ferramentas para a melhoria da segurança de aplicações Web.
- #7 OWASP Top Ten é uma poderosa documentação de conscientização para segurança de aplicações Web. Representa um conjunto de falhas de segurança mais comuns em sistemas Web, são ordenados considerando o risco e a prevalência da falha. Todos estes problemas são encontrados na infraestrutura de instituições financeiras, saúde, defesa, energia e outros setores. O objetivo é que as organizações comecem com segurança suas aplicações e os desenvolvedores possam aprender com os erros de outras organizações e, para os executivos uma oportunidade de pensar em gerenciar riscos de seus softwares.
- #11 Demonstração: https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-2481
- #12 https://www.bugzilla.org/security/
- #13 Um ataque CSRF força a vítima que possui uma sessão ativa em um navegador a enviar uma requisição HTTP forjada, incluindo o cookie da sessão da vítima e qualquer outra informação de autenticação incluída na sessão, a uma aplicação web vulnerável. Esta falha permite ao atacante forçar o navegador da vítima a criar requisições que a aplicação vulnerável aceite como requisições legítimas realizadas pela vítima.
- #14 Demonstração vídeo “8 Cross-Site Request Forgery.avi”
- #16 A maioria das aplicações web verificam os direitos de acesso em nível de função antes de tornar essa funcionalidade visível na interface do usuário. No entanto, as aplicações precisam executar as mesmas verificações de controle de acesso no servidor quando cada função é invocada. Se estas requisições não forem verificadas, os atacantes serão capazes de forjar as requisições, com o propósito de acessar a funcionalidade sem autorização adequada.
- #17 Como evitar?
- #18 Muitas aplicações web não protegem devidamente os dados sensíveis, tais como cartões de crédito, IDs fiscais e credenciais de autenticação. Os atacantes podem roubar ou modificar esses dados desprotegidos com o propósito de realizar fraudes de cartões de crédito, roubo de identidade, ou outros crimes. Os dados sensíveis merecem proteção extra como criptografia no armazenamento ou em trânsito, bem como precauções especiais quando trafegadas pelo navegador.
- #19 Como evitar?
- #20 Uma boa segurança exige a definição de uma configuração segura e implementada na aplicação, frameworks, servidor de aplicação, servidor web, banco de dados e plataforma. Todas essas configurações devem ser definidas, implementadas e mantidas, já que geralmente a configuração padrão é insegura. Adicionalmente, o software deve ser mantido atualizado.
- #22 Uma referência insegura e direta a um objeto ocorre quando um programador expõe uma referência à implementação interna de um objeto, como um arquivo, diretório, ou registro da base de dados. Sem a verificação do controle de acesso ou outra proteção, os atacantes podem manipular estas referências para acessar dados não-autorizados.
- #24 Falhas XSS ocorrem sempre que uma aplicação recebe dados não confiáveis e os envia ao navegador sem validação ou filtro adequados. XSS permite aos atacantes executarem scripts no navegador da vítima que podem “sequestrar” sessões do usuário, desfigurar sites, ou redirecionar o usuário para sites maliciosos.
- #26 As funções da aplicação relacionadas com autenticação e gerenciamento de sessão geralmente são implementadas de forma incorreta, permitindo que os atacantes comprometam senhas, chaves e tokens de sessão ou, ainda, explorem outra falha da implementação para assumir a identidade de outros usuários.
- #27 Como evitar?
- #29 Como evitar?
- #30 Como evitar?
- #31 Como evitar?