OWASP Top 10 - Experiência e Cases com Auditorias Teste de Invasão em Aplicações Web

14.521 visualizações

Publicada em

Título: OWASP Top 10
- Experiência e Cases com Auditorias Teste de Invasão em Aplicações Web

Proposta: Esta palestra visa apresentar exemplos de vulnerabilidades mais comumente encontradas e más práticas de segurança detectadas em auditorias teste de invasão em aplicações web já realizadas e medidas simples que podem aumentar consideravelmente o nível de segurança e evitar incidentes graves em ambientes deste tipo. Além disto, será apresentada também a experiência da Clavis Segurança da Informação enquanto empresa de consultoria especializada ao realizar auditorias desta espécie tanto in-company quanto remotamente.

Cursos e Soluções Relacionados:

Formação de 100 horas – Auditor em Teste de Invasão – Pentest – Academia Clavis Segurança da Informação
http://www.blog.clavis.com.br/formacao-de-78-horas-auditor-em-teste-de-invasao-academia-clavis-seguranca-da-informacao/

Auditoria de Segurança em Aplicações Web
http://www.clavis.com.br/servico/servico-auditoria-seguranca-da-informacao-aplicacoes-web.php

Palestrante: Rafael Soares Ferreira

Sobre o Instrutor: Rafael Soares Ferreira é Diretor Técnico do Grupo Clavis Segurança da Informação, e é profissional atuante nas áreas de análise forense computacional, detecção e resposta a incidentes de segurança, testes de invasão e auditorias de rede, sistemas e aplicações. Já prestou serviços e ministrou cursos e palestras sobre segurança da informação para grandes empresas nacionais, internacionais, órgãos públicos e militares, assim como em diversos eventos, entre eles: FISL – Fórum Internacional de Software Livre, EnCSIRTs – Encontro de CSIRTs Acadêmicos, SegInfo – Workshop de Segurança da Informação, Congresso Digital, Fórum de Software Livre do Rio de Janeiro, Web Security Forum, Ultra SL – Ultra Maratona How To de Software Livre, FLISOL, entre outros. Na Academia Clavis é instrutor dos seguintes cursos: Certified Ethical Hacker (CEH), Teste de Invasão em Redes e Sistemas, Auditoria de Segurança em Aplicações Web,Análise Forense Computacional, Teste de Invasão em Redes e Sistemas EAD, Auditoria de Segurança em Aplicações Web EAD e Análise Forense Computacional EAD. Possui as certificações CEH (Certified Ethical Hacker) e SANS SSP-CNSA.

Publicada em: Tecnologia
0 comentários
7 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
14.521
No SlideShare
0
A partir de incorporações
0
Número de incorporações
10.003
Ações
Compartilhamentos
0
Downloads
129
Comentários
0
Gostaram
7
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide
  • Rafael Soares Ferreira é Diretor Técnico do Grupo Clavis Segurança da Informação, e é profissional atuante nas áreas de análise forense computacional, detecção e resposta a incidentes de segurança, testes de invasão e auditorias de rede, sistemas e aplicações. Já prestou serviços e ministrou cursos e palestras sobre segurança da informação para grandes empresas nacionais, internacionais, órgãos públicos e militares, assim como em diversos eventos, entre eles: FISL - Fórum Internacional de Software Livre, EnCSIRTs - Encontro de CSIRTs Acadêmicos, SegInfo - Workshop de Segurança da Informação, Congresso Digital, Fórum de Software Livre do Rio de Janeiro, Web Security Forum, Ultra SL - Ultra Maratona How To de Software Livre, FLISOL, entre outros. Na Academia Clavis é instrutor dos seguintes cursos: Certified Ethical Hacker (CEH), Teste de Invasão em Redes e Sistemas, Auditoria de Segurança em Aplicações Web, Análise Forense Computacional, Teste de Invasão em Redes e Sistemas EAD, Auditoria de Segurança em Aplicações Web EAD e Análise Forense Computacional EAD. Possui as certificações CEH (Certified Ethical Hacker) e SANS SSP-CNSA. Tem especial interesse nas seguintes áreas: Análise forense computacional; Detecção e resposta a incidentes de segurança; Testes de invasão e auditorias de rede, sistemas e aplicações.
  • ________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
  • As falhas de injeção, em especial SQL Injection , são comuns em aplicações Web. A injeção ocorre quando os dados fornecidos pelo usuário são enviados a um interpretador com parte do comando ou consulta. A informação maliciosa fornecida pelo atacante engana o interpretador que irá executar comandos mal intencionados ou manipular informações Referências: http://www.matped.com/2009/07/injecao-codigo-paginas-php/
  • ________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
  • ________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
  • ________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
  • ________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
  • ________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
  • ________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
  • ________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
  • Referências: https://www.owasp.org/index.php/Broken_Authentication_and_Session_Management
  • Referências: http://www.thc.org/thc-hydra/ http://tcpreplay.synfin.net/
  • Referências: https://www.owasp.org/index.php/Authentication_Cheat_Sheet
  • ________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
  • Uma referência direta à objeto ocorre quando um desenvolvedor expõe a referência a um objeto implementado internamente, como é o caso de arquivos, diretórios, registros da base de dados ou chaves, na forma de uma URL ou parâmetro de formulário. Os atacantes podem manipular estas referências para acessar outros objetos sem autorização. Referências: http://serdarbuyuktemiz.blogspot.com/2008/09/insecure-direct-object-reference.html
  • ________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
  • ________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
  • Um ataque CSRF força o navegador da vítima, que esteja autenticado em uma aplicação, a enviar uma requisição pré-autenticada a um servidor Web vulnerável, que por sua vez força o navegador da vítima a executar uma ação maliciosa em prol do atacante Referências: http://www.veracode.com/security/csrf http://www.securitytube.net/video/196
  • ________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
  • Referências: https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet https://www.owasp.org/index.php/Category:OWASP_CSRFGuard_Project
  • ________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
  • ________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
  • Referências: http://www.moneycontrol.com/news-topic/internet-security-company-/video-firewall-ips-ids-systems-and-vulnerability-management-tutorial-guidewmv_ECAWAcZ80tg.html
  • ________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
  • Atacantes tipicamente não contornam os algoritmos de criptografia em si, mas exploram outras brechas que permitem obter chaves ou cópias de dados em texto claro ( backups ), ou acessar dados via canais que descriptografam automaticamente. Dados sensíveis trafegados sem criptografia são capturados pela simples interceptação de tráfego Senhas protegidas por métodos de criptografia em uma só via podem ser quebradas através de “ Rainbow Tables ” Projetos relacionados a Rainbow Tables : http://regenboog.yellosoft.us/ http://project-rainbowcrack.com/ http://lasecwww.epfl.ch/~oechslin/projects/ophcrack
  • O comprometimento pode ser parcial se forem utilizadas diversas chaves protegendo dados de diferentes tipos. Assim, quando uma chave é comprometida, os dados criptografas com outras chaves permanecem seguros. É importante ter em mente que cópias dos dados ( backups , servidores de teste internos) também devem ser protegidos.
  • Riscos associados a métodos de criptografia inseguros envolvem conceitos de criptoanálise para contornar matematicamente este métodos e por isto estão fora do escopo da apresentação A escolha do algoritmo de criptografia também depende dos requisitos da aplicação. Um algoritmo considerado não tão forte pode ser escolhido por seu desempenho. Neste caso, é importante trocar regularmente as chaves de criptografia. Métodos de criptografia em uma só via também devem ser escolhidos apropriadamente, pois, geralmente nas aplicações web, o método é aplicado no lado do cliente, de forma que o procedimento que o executa fica exposto.
  • ________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
  • A falha está relacionada a possibilidade de contornar o mecanismo de autorização da aplicação web só pela modificação da URL. Por exemplo, dado um usuário conectado legitimamente à URL: http://www.aplicacao_web.com/sistema Se este usuário editar a URL e acessar, por exemplo: http://www.aplicacao_web.com/admin Por ele já estar autenticado em “ /sistema ” , ele pode entrar em “ /admin ” ? Ou pior, um usuário não autenticado pode acessar diretamente “ /admin ” ?
  • O comprometimento não está relacionado a roubo de credenciais de acesso, mas a personificação do usuário ( im personation attack ), onde o atacante se faz passar por outro usuário, tendo acesso à informação que o usuário tem permissão para acessar Uma vez executado o ataque, o atacante terá, provavelmente, a oportunidade de modificar as credenciais de acesso do usuário, mas esta ação é característica deste ataque e sim um produto do mesmo.
  • É fundamental ter muito bem definido o que se trata de informação pública (não requer credenciais) e privada (requer credenciais) e então proteger a informação privada. Políticas mais restritivas ( block all, allow some ) são mais adequadas que as mais permissivas (allow all, block some ), pois os casos não previstos são bloqueados e o acesso é liberado sob demanda. No caso de acessos automatizados, é importante fazer as verificações corretamente, pois um atacante pode simular um acesso automatizado para contornar os mecanismos de proteção.
  • ________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
  • A falha diz respeito ao problemas na proteção dos dados trafegados pela Internet. No caso das aplicações web, refere-se ao uso criptografia sobre o protocolo HTTP (HTTPS) Se a criptografia for utilizada somente para a autenticação, o atacante não poderá interceptar as credenciais de acesso, mas poderá interceptar o ID de seção e personificar o usuário ( impersonation attack ), a fim de acessar informações que o usuário tem permissão para acessar
  • Se não houver nenhuma proteção no transporte de dados, o atacante pode interceptá-los quando trafegam na rede, incluindo credenciais de acesso, informações pessoais, dados da aplicação, etc O uso de certificados auto-assinados é prejudicial à confiabilidade da aplicação e facilita a execução de ataques MITM, que, em geral, utilizam certificados auto-assinados (se o browser sempre apresenta o aviso alertando sobre o certificado auto-assinado, o usuário pode não perceber a diferença entre o certificado usual e o do atacante). É importante proteger também conexões de back end , pois estas podem revelar informações confidenciais ou que podem ser usadas para executar um ataque vindo da rede interna
  • Para proteger somente os dados privados, é preciso diferenciar os dados públicos dos privados e verificar a transição entre a transmissão de dados públicos e protegidos e vice-versa É importante também que a aplicação não aceite requisições contendo dados privados por canais inseguros, pois um atacante pode modificar a URL da aplicação e enviá-la a um usuário autenticado para interceptar os dados transmitidos por este usuário ao acessar esta URL modificada A flag 'secure ' dos cookies estipula que o cookie só pode ser transmitido através de um canal seguro
  • ________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
  • A falha diz respeito a manipulação de repasses ( forwards ) e redirecionamentos legítimos presentes na aplicação para destinos arbitrários controlados pelo atacante. Um ataque deste tipo, em geral, é muito similar a um ataque de injeção comum, mas difere quanto ao objetivo A falha de validação pode permitir que o atacante manipule um redirecionamento interno para um destino externo arbitrário
  • Um atacante pode redirecionar o atacante para um site malicioso a fim de instalar malware , para uma cópia do site para induzir o usuário a inserir suas credenciais de acesso, para um site que repassa requisições para o servidor web original ( Man-In-The-Middle attack ), etc O atacante pode manipular redirecionamentos internos para acessar páginas privadas ou para contornar mecanismos de autorização (escalada de privilégios) Ataques deste tipo contém uma etapa de engenharia social, pois o redirecionamento em si não configura dano obrigatoriamente, mas o que o usuário é induzido a fazer, uma vez redirecionado, que em geral é danosa
  • Estas falhas são úteis para os phishers , pois o endereço é enviado no phishing scam é, de fato, legítimo, mas redireciona para um destino arbitrário Ao se utilizar valores mapeados (tabelas hash ) só será possível redirecionar para os destinos pré-definidos, assim ainda que o redirecionamento tenha sido manipulado, é mais simples fazer os controles de autorização, pois os possíveis destinos estão restritos aos destinos mapeados. A ESAPI é uma API para desenvolvimento de aplicações web desenvolvida pela OWASP e inclui módulos de validação de entradas, codificação de saídas, autenticação, etc
  • ________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
  • OWASP Top 10 - Experiência e Cases com Auditorias Teste de Invasão em Aplicações Web

    1. 1. OWASP Top 10Principais Vulnerabilidades em Aplicações Web Rafael Soares Ferreira Sócio Diretor Técnico rafael@clavis.com.br
    2. 2. $ whoami • Grupo Clavis • Sócio Diretor Técnico • Detecção e resposta a incidentes de segurança • Testes de invasão em redes, sistemas e aplicações.
    3. 3. Principais Ameaças Injeções
    4. 4. Descrição • Ocorre quando a aplicação envia dados não tratados para algum serviço interno. • Pode ser feita via SQL, LDAP, Xpath, comandos de sistema operacional, argumentos de programas, etc. • Descoberta por varreduras e/ou fuzzers • Mais facilmente por verificação de código.
    5. 5. Impactos • Dependendo do tipo de injeção os danos causados podem ser:  Perda ou corrupção de dados  Negação de Serviço  Falhas de autenticação  Execução arbitrária de código e até comprometimento total do sistema.
    6. 6. Como se Prevenir • Não utilizar dados não confiáveis em comandos e/ou queries. • Rotinas de validação ou “escape” de caracteres. • É aconselhável o uso de validação positiva nas entradas. • Utilizar canonicalização de dados.
    7. 7. Principais Ameaças XSS – Cross Site Scripting
    8. 8. Descrição • Ocorre quando uma aplicação inclui dados não tratados em um objeto enviado ao navegador. • A detecção pode ser feita via teste de injeção ou análise de código. • Existem 3 principais tipos:  Stored  Reflected  DOM based XSS
    9. 9. Impactos • Atacante pode executar scripts no navegador da vítima para:  Roubo de informações de sessão  Pichação de Sites  Inserção de conteúdo malicioso  Redirecionamento de usuários e etc. • Além da exposição de informações dos usuários, tal falha pode denegrir a imagem da instituição responsável pela aplicação.
    10. 10. Como se Prevenir • “Escapar” caracteres vindo de fontes não confiáveis e que serão utilizados no contexto do navegador (body, atributos, JavaScript, CSS, URL). • A validação positiva é sempre interessante mas é preciso atentar para peculiaridades da aplicação em questão pois caracteres especiais e codificações diversas podem fazer parte da rotina da aplicação.
    11. 11. Principais Ameaças Quebra de Autenticação / Sessão
    12. 12. Definição Quebra de Autenticação / Sessão • Restrição de conteúdos / recursos  Autenticação HTTP: Basic -> credenciais concatenadas separadas por “:” e codificadas em base64 Digest -> hash MD5
    13. 13. Impacto Quebra de Autenticação / Sessão HTTP digest: Força-bruta Hydra (http://freeworld.thc.org/thc-hydra/) Replay de tráfego TCPReplay (http://tcpreplay.synfin.net/trac/)
    14. 14. Como se Prevenir Quebra de Autenticação / Sessão  Tunelameto por SSL  Políticas de segurança  CAPTCHA  OWASP Authentication_Cheat_Sheet
    15. 15. Principais Ameaças Referência Direta a Objetos
    16. 16. Definição Referência Direta a Objetos • Exposição de informações internas • Evite Controle de Acesso em camada de apresentação  Modificações de informações para acesso a dados não autorizados
    17. 17. Impacto Referência Direta a Objetos • Evite expor referências a objetos internos  Validação de referências  Mapas de referência Ex: http://www.example.com/application?file=1
    18. 18. Principais Ameaças Cross Site Request Forgery
    19. 19. Definição Cross Site Request Forgery (CSRF) • Browsers enviam alguns tipos de credenciais automaticamente em cada requisição Cookies Cabeçalhos Endereço IP Certificados SSL
    20. 20. Impacto Cross Site Request Forgery (CSRF) • A vítima acessa um site malicioso enquanto está logada no sistema vulnerável  O atacante força a vítima a fazer tal  requisição
    21. 21. Como se Prevenir Cross Site Request Forgery (CSRF) • Autenticações forçadas em requisições sensíveis  Controle exposição de dados utilizados  como credenciais  OWASP: CSRF_Prevention_Cheat_Sheet
    22. 22. Principais Ameaças Falhas de Configuração
    23. 23. Definição Falhas de Configuração • Aplicações rodam em cima de serviços que rodam em cima de SOs • Todos podem ser vetores de ataque • Exploits (e patchs!) se aplicam à qualquer tipo de software
    24. 24. Como se Prevenir Falhas de Configuração • “Hardening” de servidores  Patchs e atualizações  Homologação de mudanças  Vulnerability Management
    25. 25. Principais Ameaças Armazenamento com métodos Inseguros
    26. 26. Descrição  Falha mais comum e grave: simplesmente não criptografar dados sensíveis  Falhas quando a criptografia é empregada: − Geração e armazenamento inseguros de chaves − Não implantar políticas de rotação de chaves − Utilizar algoritmos de criptografia fracos − Utilizar métodos de criptografia em uma só via (hash) fracos ou sem salto para proteger senhas.
    27. 27. Impacto  Frequentemente comprometem todos os dados protegidos por criptografia  Tipicamente, estes dados incluem, mas não estão limitados à: − Credenciais de acesso − Dados pessoais − Registros de saúde − Cartões de crédito, etc.
    28. 28. Como se Previnir  Requisitos mínimos para armazenamento de dados em aplicações web: − Algoritmos de criptografia e chaves utilizados devem ser apropriadamente fortes. − Chaves e senhas devem estar protegidas de acesso não autorizado. − Senhas devem armazenadas em hash com um algoritmo de criptografia em uma só via forte e com um salto apropriado.
    29. 29. Principais Ameaças Falha em restringir acesso à URL
    30. 30. Descrição  Falha em proteger requisições da página apropriadamente  Falhas básicas de fácil detecção, uma vez listadas todas as páginas (URLs) que existem para atacar.
    31. 31. Impacto  Frequentemente, contas privilegiadas são o alvo deste tipo de ataque  Uma vez bem sucedido, o atacante pode fazer qualquer coisa que a vítima poderia fazer
    32. 32. Como se Prevenir • É fundamental ter muito bem definido o que se trata de informação pública (não requer credenciais) e privada (requer credenciais) e então proteger a informação privada. • Políticas mais restritivas (block all, allow some) são mais adequadas que as mais permissivas (allow all, block some), pois os casos não previstos são bloqueados e o acesso é liberado sob demanda.
    33. 33. Principais Ameaças Proteção Insuficiente no Transporte de Dados
    34. 34. Descrição  Falha em proteger o tráfego de rede onde passam os dados da aplicação  Utilização de criptografia somente na autenticação (expondo dados e IDs de seção)  Utilização de certificados expirados ou mal configurados
    35. 35. Impacto  Estas falhas expõe dados de usuários e podem conduzir a roubo de contas.  Se uma conta de administração for comprometida, o site inteiro pode ser exposto.  Utilizar de métodos de criptografia mal configurados também podem facilitar ataques de phishing e Man-In-The-Middle (MITM)
    36. 36. Como se Prevenir • É importante que a aplicação não aceite requisições contendo dados privados por canais inseguros • A flag secure dos cookies estipula que o cookie só pode ser transmitido através de um canal seguro
    37. 37. Principais Ameaças Redirecionamentos e repasses não validados
    38. 38. Descrição  Falha em validar o destino de redirecionamentos ou repasses utilizados  Problemas mais comuns: − Ausência de validação do destino de um redirecionamento ou repasse − Similaridade entre redirecionamento para destinos internos (da própria aplicação) e externos
    39. 39. Impacto  Redirecionamentos podem induzir usuários a instalar malware ou revelar informações sensíveis.  Repasses inseguros podem permitir contornar controles de acesso.
    40. 40. Como se Prevenir  Recomendações básicas para utilizar redirecionamentos e repasses: − Não envolver parâmetros de usuário para calcular o destino − Se não puder evitar, validar o parâmetro e verificar autorização do usuário
    41. 41. Dúvidas?
    42. 42. Siga a Clavis
    43. 43. Muito Obrigado! rafael@clavis.com.br @rafaelsferreira Rafael Soares Ferreira Sócio Diretor Técnico

    ×