SlideShare uma empresa Scribd logo
1 de 36
Segurança na WEB
Evite os tipos mais comuns de ataques
Kaito Queiroz
O que são Riscos de
Segurança em Aplicações?
Os atacantes podem, potencialmente, usar vários
caminhos diferentes através da sua aplicação para
causar danos ao seu negócio ou organização.
Agentes de Ameaça
> Explora as falhas
> Tenta obter alguma vantagem
> Tempo de sobra
> Deve ser levado a sério
Devemos conhecer nossas
fraquezas
> Equipes capazes de identificar falhas e corrigí-las
> Conhecer técnicas de invasões
> Planejar, Desenvolver e Verificar aplicações confiáveis
> Aprender com os próprios erros...
> ...e dos outros.
Open Web Application Security Project (OWASP) é uma
comunidade aberta, dedicada a capacitar as
organizações a desenvolver, adquirir e manter
aplicações confiáveis.
https://www.owasp.org/
OWASP TOP 10
O OWASP Top 10 tem seu foco na identificação dos
riscos mais graves para uma ampla gama de
organizações.
> OWASP Risk Rating Methodology
A10 - Redirecionamentos e
Encaminhamentos Inválidos
Exemplos de Cenários de Ataque
A10 - Redirecionamentos e
Encaminhamentos Inválidos
Como evitar?
A10 - Redirecionamentos e
Encaminhamentos Inválidos
❏ Simplesmente evitar usá-los
❏ Se forem usados, não envolva parâmetros do usuário no cálculo do destino.
Normalmente, isto pode ser feito.
❏ Se os parâmetros de destino não podem ser evitados, tenha certeza que o
valor fornecido é válido, e autorizado para o usuário
A9 - Utilização de Componentes
Vulneráveis Conhecidos
Exemplos de Cenários de Ataque
❏ Apache CXF Authentication Bypass – Ao não fornecer um token de
identidade, atacantes podem chamar qualquer serviço web com todas as
permissões.
❏ Spring Remote Code Execution – Abuso da implementação de Linguagem
Expression no Spring permitiu aos atacantes executarem código arbitrário,
efetivamente comprometendo o servidor.
❏ Wordpress Jetpack Plugin - Foi possível injetar código Javascript malicioso
A9 - Utilização de Componentes
Vulneráveis Conhecidos
Como evitar?
❏ Evitar de usar componentes de terceiros
❏ Muitos projetos de componentes não criam correções de vulnerabilidades
para versões antigas. Em vez disso, é mais simples corrigir o problema na
próxima versão. Então atualizar para essas novas versões é crítico.
A9 - Utilização de Componentes
Vulneráveis Conhecidos
Como evitar?
Projetos de software devem ter processos para:
a) Identificar todos os componentes e as versões que você está utilizando, incluindo todas as
dependências. (ex., versões dos plugins).
b) Monitorar a segurança desses componentes em banco de dados públicos, listas de e-mail de
projetos e segurança, e mantê-los atualizados.
c) Estabelecer políticas de segurança que definam o uso do componente, assim como exigir
certas práticas de desenvolvimento de software, passando em testes de segurança, e
licenças aceitáveis.
d) Quando apropriado, considere a adição de invólucros de segurança em torno dos
componentes para desabilitar funcionalidades não utilizadas e/ou proteger falhas ou aspectos
vulneráveis do componente.
A9 - Utilização de Componentes
Vulneráveis Conhecidos
A8 - Cross-Site Request
Forgery (CSRF)
A8 - Cross-Site Request
Forgery (CSRF)
A aplicação permite que um usuário submeta uma requisição de mudança de
estado que não inclui qualquer segredo.
Por exemplo:
Exemplos de Cenários de Ataque
A8 - Cross-Site Request
Forgery (CSRF)
Com isso, o atacante constrói uma requisição que irá transferir dinheiro da conta da vítima para a conta
do atacante, e então incorpora este ataque em uma requisição armazenada em uma imagem ou iframe
em vários sites sob o controle do atacante:
Exemplos de Cenários de Ataque
Como evitar?
A prevenção de um CSRF geralmente requer a inclusão de um token imprevisível em cada
requisição HTTP. Tais tokens devem, no mínimo, ser únicos por sessão de usuário.
1. A opção preferida consiste em incluir um token único em um campo oculto. Isso faz com
que o valor seja enviado no corpo da requisição HTTP, evitando-se a sua inserção na URL, que é
mais propensa a exposição.
2. O token único pode ser incluído na própria URL, ou em parâmetros da URL. Contudo, tal
posicionamento corre um risco maior já que a URL será exposta ao atacante, comprometendo
assim o token secreto
A8 - Cross-Site Request
Forgery (CSRF)
Como evitar?
O CSRF Guard do OWASP pode incluir tokens automaticamente em aplicações
Java EE, .NET ou PHP. A ESAPI do OWASP disponibiliza métodos para
desenvolvedores utilizarem na prevenção de vulnerabilidades de CSRF.
3. Exigir que o usuário autentique novamente, ou provar que são realmente
um usuário (por exemplo, através de CAPTCHA) também pode proteger contra
CSRF.
A8 - Cross-Site Request
Forgery (CSRF)
A7 - Falta de Função para
Controle do Nível de Acesso
A7 - Falta de Função para
Controle do Nível de Acesso
1: O atacante simplesmente força a navegação pelas URLs alvo. As seguintes URLs exigem autenticação.
Direitos de administrador também são exigidos para acessar a página “admin_getappInfo” .
http://example.com/app/getappInfo
http://example.com/app/admin_getappInfo
Se um usuário não autenticado pode acessar qualquer página, isso é uma falha.
Exemplos de Cenários de Ataque
A7 - Falta de Função para
Controle do Nível de Acesso
Frequentemente, tal proteção é fornecida por um ou mais componentes externos ao código da
aplicação.
1. Pense sobre o processo para gerenciar os direitos e garantir que você possa atualizar e auditar
facilmente. Não codifique diretamente.
2. A execução de mecanismos deve negar todo o acesso por padrão, exigindo direitos explícitos
para papéis específicos no acesso a todas as funções.
3. Se a função está envolvida em um fluxo de trabalho, verifique, para ter certeza, se as
condições estão em estado adequado para permitir acesso.
Como evitar?
A6 - Exposição de Dados
Sensíveis
Exemplos de Cenários de Ataque
A6 - Exposição de Dados
Sensíveis
Exemplos de Cenários de Ataque
A6 - Exposição de Dados
Sensíveis
Como evitar?
> Dados Criptografados (https)
> Dasabilitar autocomple
A5 - Configuração Incorreta
de Segurança
Exemplos de Cenários de Ataque
A4 - Referência Insegura e
Direta a Objetos
A4 - Referência Insegura e
Direta a Objetos
A4 - Referência Insegura e
Direta a Objetos
A3 - Cross-Site Scripting
(XSS)
A3 - Cross-Site Scripting
(XSS)
Exemplos de Cenários de Ataque
A3 - Cross-Site Scripting
(XSS)
> Validar toda entrada de dados
> Sanitize
Como evitar?
A2 - Quebra de Autenticação
e Gerenciamento de Sessão
Exemplos de Cenários de Ataque
A1 - Injeção
A1 - Injeção
Exemplos de Cenários de Ataque
A1 - Injeção
Como evitar?

Mais conteúdo relacionado

Mais procurados

AppSec Latam 2011 - Treinamento OWASP Top 10 + JavaEE
AppSec Latam 2011 - Treinamento OWASP Top 10 + JavaEEAppSec Latam 2011 - Treinamento OWASP Top 10 + JavaEE
AppSec Latam 2011 - Treinamento OWASP Top 10 + JavaEEMagno Logan
 
Seguranca web Testday2012
Seguranca web Testday2012Seguranca web Testday2012
Seguranca web Testday2012Marcio Cunha
 
Workshop - Testes de Segurança
Workshop - Testes de SegurançaWorkshop - Testes de Segurança
Workshop - Testes de SegurançaAlan Carlos
 
Cross Site Scripting - XSS
Cross Site Scripting - XSSCross Site Scripting - XSS
Cross Site Scripting - XSSDiego Souza
 
Segurança de Redes
Segurança de RedesSegurança de Redes
Segurança de RedesCassio Ramos
 
Segurança em PHP - Blinde seu código de você mesmo!
Segurança em PHP - Blinde seu código de você mesmo!Segurança em PHP - Blinde seu código de você mesmo!
Segurança em PHP - Blinde seu código de você mesmo!Gustavo Neves
 
Desenvolvendo sistemas seguros com PHP
Desenvolvendo sistemas seguros com PHPDesenvolvendo sistemas seguros com PHP
Desenvolvendo sistemas seguros com PHPFlavio Souza
 
Aprendendo a atacar (e proteger) aplicações web através de jogos de guerra
Aprendendo a atacar (e proteger) aplicações web através de jogos de guerraAprendendo a atacar (e proteger) aplicações web através de jogos de guerra
Aprendendo a atacar (e proteger) aplicações web através de jogos de guerraClavis Segurança da Informação
 
Tutorial: Principais Vulnerabilidades em Aplicações Web – Rafael Soares Ferre...
Tutorial: Principais Vulnerabilidades em Aplicações Web – Rafael Soares Ferre...Tutorial: Principais Vulnerabilidades em Aplicações Web – Rafael Soares Ferre...
Tutorial: Principais Vulnerabilidades em Aplicações Web – Rafael Soares Ferre...Clavis Segurança da Informação
 
"Técnicas e Ferramentas para Auditorias Testes de Invasão"
"Técnicas e Ferramentas para Auditorias Testes de Invasão" "Técnicas e Ferramentas para Auditorias Testes de Invasão"
"Técnicas e Ferramentas para Auditorias Testes de Invasão" Clavis Segurança da Informação
 
Site blindado - Como tornar loja virtual mais segura e vender mais
Site blindado  - Como tornar loja virtual mais segura e vender maisSite blindado  - Como tornar loja virtual mais segura e vender mais
Site blindado - Como tornar loja virtual mais segura e vender maisMauro Risonho de Paula Assumpcao
 

Mais procurados (18)

Aula 10 - Cross Site Scripting (XSS)
Aula 10 - Cross Site Scripting (XSS)Aula 10 - Cross Site Scripting (XSS)
Aula 10 - Cross Site Scripting (XSS)
 
Saia do 7x0 com testes de segurança
Saia do 7x0 com testes de segurançaSaia do 7x0 com testes de segurança
Saia do 7x0 com testes de segurança
 
AppSec Latam 2011 - Treinamento OWASP Top 10 + JavaEE
AppSec Latam 2011 - Treinamento OWASP Top 10 + JavaEEAppSec Latam 2011 - Treinamento OWASP Top 10 + JavaEE
AppSec Latam 2011 - Treinamento OWASP Top 10 + JavaEE
 
OWASP Top Ten
OWASP Top TenOWASP Top Ten
OWASP Top Ten
 
Seguranca web Testday2012
Seguranca web Testday2012Seguranca web Testday2012
Seguranca web Testday2012
 
backdoors
backdoorsbackdoors
backdoors
 
Workshop - Testes de Segurança
Workshop - Testes de SegurançaWorkshop - Testes de Segurança
Workshop - Testes de Segurança
 
Cross Site Scripting - XSS
Cross Site Scripting - XSSCross Site Scripting - XSS
Cross Site Scripting - XSS
 
Segurança de Redes
Segurança de RedesSegurança de Redes
Segurança de Redes
 
Cross Site Scripting
Cross Site Scripting Cross Site Scripting
Cross Site Scripting
 
Segurança em PHP - Blinde seu código de você mesmo!
Segurança em PHP - Blinde seu código de você mesmo!Segurança em PHP - Blinde seu código de você mesmo!
Segurança em PHP - Blinde seu código de você mesmo!
 
Desenvolvendo sistemas seguros com PHP
Desenvolvendo sistemas seguros com PHPDesenvolvendo sistemas seguros com PHP
Desenvolvendo sistemas seguros com PHP
 
Aprendendo a atacar (e proteger) aplicações web através de jogos de guerra
Aprendendo a atacar (e proteger) aplicações web através de jogos de guerraAprendendo a atacar (e proteger) aplicações web através de jogos de guerra
Aprendendo a atacar (e proteger) aplicações web através de jogos de guerra
 
Treinamento ajax 05
Treinamento ajax   05Treinamento ajax   05
Treinamento ajax 05
 
Tutorial: Principais Vulnerabilidades em Aplicações Web – Rafael Soares Ferre...
Tutorial: Principais Vulnerabilidades em Aplicações Web – Rafael Soares Ferre...Tutorial: Principais Vulnerabilidades em Aplicações Web – Rafael Soares Ferre...
Tutorial: Principais Vulnerabilidades em Aplicações Web – Rafael Soares Ferre...
 
"Técnicas e Ferramentas para Auditorias Testes de Invasão"
"Técnicas e Ferramentas para Auditorias Testes de Invasão" "Técnicas e Ferramentas para Auditorias Testes de Invasão"
"Técnicas e Ferramentas para Auditorias Testes de Invasão"
 
Tratando as vulnerabilidades do Top 10 com php
Tratando as vulnerabilidades do Top 10 com phpTratando as vulnerabilidades do Top 10 com php
Tratando as vulnerabilidades do Top 10 com php
 
Site blindado - Como tornar loja virtual mais segura e vender mais
Site blindado  - Como tornar loja virtual mais segura e vender maisSite blindado  - Como tornar loja virtual mais segura e vender mais
Site blindado - Como tornar loja virtual mais segura e vender mais
 

Semelhante a Segurança WEB riscos

AppSec Brazil 2010 - Utilizando a ESAPI para prover Segurança em Aplicações W...
AppSec Brazil 2010 - Utilizando a ESAPI para prover Segurança em Aplicações W...AppSec Brazil 2010 - Utilizando a ESAPI para prover Segurança em Aplicações W...
AppSec Brazil 2010 - Utilizando a ESAPI para prover Segurança em Aplicações W...Magno Logan
 
Explorando 5 falhas graves de segurança que todos programadores cometem
Explorando 5 falhas graves de segurança que todos programadores cometem Explorando 5 falhas graves de segurança que todos programadores cometem
Explorando 5 falhas graves de segurança que todos programadores cometem Alcyon Ferreira de Souza Junior, MSc
 
Explorando 5 falhas graves de segurança que os programadores sempre cometem
Explorando 5 falhas graves de segurança que os programadores sempre cometemExplorando 5 falhas graves de segurança que os programadores sempre cometem
Explorando 5 falhas graves de segurança que os programadores sempre cometemAlcyon Ferreira de Souza Junior, MSc
 
CJR Apresenta: OWASP TOP10
CJR Apresenta: OWASP TOP10CJR Apresenta: OWASP TOP10
CJR Apresenta: OWASP TOP10CJR, UnB
 
Palestra em parceria com o @cefet_rj – Auditoria Teste de Invasão em Aplicações
Palestra em parceria com o @cefet_rj – Auditoria Teste de Invasão em AplicaçõesPalestra em parceria com o @cefet_rj – Auditoria Teste de Invasão em Aplicações
Palestra em parceria com o @cefet_rj – Auditoria Teste de Invasão em AplicaçõesClavis Segurança da Informação
 
Website security
Website securityWebsite security
Website securitythiagosenac
 
Construindo uma Aplicação PHP à Prova de Balas
Construindo uma Aplicação PHP à Prova de BalasConstruindo uma Aplicação PHP à Prova de Balas
Construindo uma Aplicação PHP à Prova de BalasRafael Jaques
 
Construindo uma aplicação PHP à Prova de Balas - Rafael Jaques
Construindo uma aplicação PHP à Prova de Balas - Rafael JaquesConstruindo uma aplicação PHP à Prova de Balas - Rafael Jaques
Construindo uma aplicação PHP à Prova de Balas - Rafael JaquesTchelinux
 
Construindo aplicações seguras na era da agilidade
Construindo aplicações seguras na era da agilidadeConstruindo aplicações seguras na era da agilidade
Construindo aplicações seguras na era da agilidademarlongaspar
 
Engenharia de Software II - Teste de segurança de software
Engenharia de Software  II - Teste de segurança de softwareEngenharia de Software  II - Teste de segurança de software
Engenharia de Software II - Teste de segurança de softwareJuliano Padilha
 
PHP Desenvolvimento Seguro
PHP Desenvolvimento SeguroPHP Desenvolvimento Seguro
PHP Desenvolvimento SeguroFlávio Lisboa
 
Segurança em Aplicações Web conforme OWASP
Segurança em Aplicações Web conforme OWASPSegurança em Aplicações Web conforme OWASP
Segurança em Aplicações Web conforme OWASPFabiano Pereira
 
Aplicações Web ‐ Seu site está seguro?
Aplicações Web ‐ Seu site está seguro?Aplicações Web ‐ Seu site está seguro?
Aplicações Web ‐ Seu site está seguro?Alex Hübner
 

Semelhante a Segurança WEB riscos (20)

Java security
Java securityJava security
Java security
 
AppSec Brazil 2010 - Utilizando a ESAPI para prover Segurança em Aplicações W...
AppSec Brazil 2010 - Utilizando a ESAPI para prover Segurança em Aplicações W...AppSec Brazil 2010 - Utilizando a ESAPI para prover Segurança em Aplicações W...
AppSec Brazil 2010 - Utilizando a ESAPI para prover Segurança em Aplicações W...
 
Explorando 5 falhas graves de segurança que todos programadores cometem
Explorando 5 falhas graves de segurança que todos programadores cometem Explorando 5 falhas graves de segurança que todos programadores cometem
Explorando 5 falhas graves de segurança que todos programadores cometem
 
Explorando 5 falhas graves de segurança que os programadores sempre cometem
Explorando 5 falhas graves de segurança que os programadores sempre cometemExplorando 5 falhas graves de segurança que os programadores sempre cometem
Explorando 5 falhas graves de segurança que os programadores sempre cometem
 
Webgoat Project - Apresentação
Webgoat Project - ApresentaçãoWebgoat Project - Apresentação
Webgoat Project - Apresentação
 
Segurança de Aplicações WEB e OpenSource
Segurança de Aplicações WEB e OpenSourceSegurança de Aplicações WEB e OpenSource
Segurança de Aplicações WEB e OpenSource
 
CJR Apresenta: OWASP TOP10
CJR Apresenta: OWASP TOP10CJR Apresenta: OWASP TOP10
CJR Apresenta: OWASP TOP10
 
Palestra em parceria com o @cefet_rj – Auditoria Teste de Invasão em Aplicações
Palestra em parceria com o @cefet_rj – Auditoria Teste de Invasão em AplicaçõesPalestra em parceria com o @cefet_rj – Auditoria Teste de Invasão em Aplicações
Palestra em parceria com o @cefet_rj – Auditoria Teste de Invasão em Aplicações
 
Website security
Website securityWebsite security
Website security
 
Analysis of vulnerabilities in web applications - LinuxCon Brazil 2010
Analysis of vulnerabilities in web applications - LinuxCon Brazil 2010Analysis of vulnerabilities in web applications - LinuxCon Brazil 2010
Analysis of vulnerabilities in web applications - LinuxCon Brazil 2010
 
Construindo uma Aplicação PHP à Prova de Balas
Construindo uma Aplicação PHP à Prova de BalasConstruindo uma Aplicação PHP à Prova de Balas
Construindo uma Aplicação PHP à Prova de Balas
 
Construindo uma aplicação PHP à Prova de Balas - Rafael Jaques
Construindo uma aplicação PHP à Prova de Balas - Rafael JaquesConstruindo uma aplicação PHP à Prova de Balas - Rafael Jaques
Construindo uma aplicação PHP à Prova de Balas - Rafael Jaques
 
Construindo aplicações seguras na era da agilidade
Construindo aplicações seguras na era da agilidadeConstruindo aplicações seguras na era da agilidade
Construindo aplicações seguras na era da agilidade
 
Antar ferreira
Antar ferreiraAntar ferreira
Antar ferreira
 
Engenharia de Software II - Teste de segurança de software
Engenharia de Software  II - Teste de segurança de softwareEngenharia de Software  II - Teste de segurança de software
Engenharia de Software II - Teste de segurança de software
 
PHP Desenvolvimento Seguro
PHP Desenvolvimento SeguroPHP Desenvolvimento Seguro
PHP Desenvolvimento Seguro
 
Segurança em Aplicações Web conforme OWASP
Segurança em Aplicações Web conforme OWASPSegurança em Aplicações Web conforme OWASP
Segurança em Aplicações Web conforme OWASP
 
Testes de segurança em aplicações web
Testes de segurança em aplicações webTestes de segurança em aplicações web
Testes de segurança em aplicações web
 
Aplicações Web ‐ Seu site está seguro?
Aplicações Web ‐ Seu site está seguro?Aplicações Web ‐ Seu site está seguro?
Aplicações Web ‐ Seu site está seguro?
 
Pentest com Kali Linux - LatinoWare 2015
Pentest com Kali Linux  - LatinoWare 2015Pentest com Kali Linux  - LatinoWare 2015
Pentest com Kali Linux - LatinoWare 2015
 

Segurança WEB riscos

  • 1. Segurança na WEB Evite os tipos mais comuns de ataques Kaito Queiroz
  • 2. O que são Riscos de Segurança em Aplicações? Os atacantes podem, potencialmente, usar vários caminhos diferentes através da sua aplicação para causar danos ao seu negócio ou organização.
  • 3. Agentes de Ameaça > Explora as falhas > Tenta obter alguma vantagem > Tempo de sobra > Deve ser levado a sério
  • 4. Devemos conhecer nossas fraquezas > Equipes capazes de identificar falhas e corrigí-las > Conhecer técnicas de invasões > Planejar, Desenvolver e Verificar aplicações confiáveis > Aprender com os próprios erros... > ...e dos outros.
  • 5. Open Web Application Security Project (OWASP) é uma comunidade aberta, dedicada a capacitar as organizações a desenvolver, adquirir e manter aplicações confiáveis. https://www.owasp.org/
  • 6. OWASP TOP 10 O OWASP Top 10 tem seu foco na identificação dos riscos mais graves para uma ampla gama de organizações. > OWASP Risk Rating Methodology
  • 7. A10 - Redirecionamentos e Encaminhamentos Inválidos
  • 8. Exemplos de Cenários de Ataque A10 - Redirecionamentos e Encaminhamentos Inválidos
  • 9. Como evitar? A10 - Redirecionamentos e Encaminhamentos Inválidos ❏ Simplesmente evitar usá-los ❏ Se forem usados, não envolva parâmetros do usuário no cálculo do destino. Normalmente, isto pode ser feito. ❏ Se os parâmetros de destino não podem ser evitados, tenha certeza que o valor fornecido é válido, e autorizado para o usuário
  • 10. A9 - Utilização de Componentes Vulneráveis Conhecidos
  • 11. Exemplos de Cenários de Ataque ❏ Apache CXF Authentication Bypass – Ao não fornecer um token de identidade, atacantes podem chamar qualquer serviço web com todas as permissões. ❏ Spring Remote Code Execution – Abuso da implementação de Linguagem Expression no Spring permitiu aos atacantes executarem código arbitrário, efetivamente comprometendo o servidor. ❏ Wordpress Jetpack Plugin - Foi possível injetar código Javascript malicioso A9 - Utilização de Componentes Vulneráveis Conhecidos
  • 12. Como evitar? ❏ Evitar de usar componentes de terceiros ❏ Muitos projetos de componentes não criam correções de vulnerabilidades para versões antigas. Em vez disso, é mais simples corrigir o problema na próxima versão. Então atualizar para essas novas versões é crítico. A9 - Utilização de Componentes Vulneráveis Conhecidos
  • 13. Como evitar? Projetos de software devem ter processos para: a) Identificar todos os componentes e as versões que você está utilizando, incluindo todas as dependências. (ex., versões dos plugins). b) Monitorar a segurança desses componentes em banco de dados públicos, listas de e-mail de projetos e segurança, e mantê-los atualizados. c) Estabelecer políticas de segurança que definam o uso do componente, assim como exigir certas práticas de desenvolvimento de software, passando em testes de segurança, e licenças aceitáveis. d) Quando apropriado, considere a adição de invólucros de segurança em torno dos componentes para desabilitar funcionalidades não utilizadas e/ou proteger falhas ou aspectos vulneráveis do componente. A9 - Utilização de Componentes Vulneráveis Conhecidos
  • 14. A8 - Cross-Site Request Forgery (CSRF)
  • 15. A8 - Cross-Site Request Forgery (CSRF) A aplicação permite que um usuário submeta uma requisição de mudança de estado que não inclui qualquer segredo. Por exemplo: Exemplos de Cenários de Ataque
  • 16. A8 - Cross-Site Request Forgery (CSRF) Com isso, o atacante constrói uma requisição que irá transferir dinheiro da conta da vítima para a conta do atacante, e então incorpora este ataque em uma requisição armazenada em uma imagem ou iframe em vários sites sob o controle do atacante: Exemplos de Cenários de Ataque
  • 17. Como evitar? A prevenção de um CSRF geralmente requer a inclusão de um token imprevisível em cada requisição HTTP. Tais tokens devem, no mínimo, ser únicos por sessão de usuário. 1. A opção preferida consiste em incluir um token único em um campo oculto. Isso faz com que o valor seja enviado no corpo da requisição HTTP, evitando-se a sua inserção na URL, que é mais propensa a exposição. 2. O token único pode ser incluído na própria URL, ou em parâmetros da URL. Contudo, tal posicionamento corre um risco maior já que a URL será exposta ao atacante, comprometendo assim o token secreto A8 - Cross-Site Request Forgery (CSRF)
  • 18. Como evitar? O CSRF Guard do OWASP pode incluir tokens automaticamente em aplicações Java EE, .NET ou PHP. A ESAPI do OWASP disponibiliza métodos para desenvolvedores utilizarem na prevenção de vulnerabilidades de CSRF. 3. Exigir que o usuário autentique novamente, ou provar que são realmente um usuário (por exemplo, através de CAPTCHA) também pode proteger contra CSRF. A8 - Cross-Site Request Forgery (CSRF)
  • 19. A7 - Falta de Função para Controle do Nível de Acesso
  • 20. A7 - Falta de Função para Controle do Nível de Acesso 1: O atacante simplesmente força a navegação pelas URLs alvo. As seguintes URLs exigem autenticação. Direitos de administrador também são exigidos para acessar a página “admin_getappInfo” . http://example.com/app/getappInfo http://example.com/app/admin_getappInfo Se um usuário não autenticado pode acessar qualquer página, isso é uma falha. Exemplos de Cenários de Ataque
  • 21. A7 - Falta de Função para Controle do Nível de Acesso Frequentemente, tal proteção é fornecida por um ou mais componentes externos ao código da aplicação. 1. Pense sobre o processo para gerenciar os direitos e garantir que você possa atualizar e auditar facilmente. Não codifique diretamente. 2. A execução de mecanismos deve negar todo o acesso por padrão, exigindo direitos explícitos para papéis específicos no acesso a todas as funções. 3. Se a função está envolvida em um fluxo de trabalho, verifique, para ter certeza, se as condições estão em estado adequado para permitir acesso. Como evitar?
  • 22. A6 - Exposição de Dados Sensíveis Exemplos de Cenários de Ataque
  • 23. A6 - Exposição de Dados Sensíveis Exemplos de Cenários de Ataque
  • 24. A6 - Exposição de Dados Sensíveis Como evitar? > Dados Criptografados (https) > Dasabilitar autocomple
  • 25. A5 - Configuração Incorreta de Segurança Exemplos de Cenários de Ataque
  • 26. A4 - Referência Insegura e Direta a Objetos
  • 27. A4 - Referência Insegura e Direta a Objetos
  • 28. A4 - Referência Insegura e Direta a Objetos
  • 29. A3 - Cross-Site Scripting (XSS)
  • 30. A3 - Cross-Site Scripting (XSS) Exemplos de Cenários de Ataque
  • 31. A3 - Cross-Site Scripting (XSS) > Validar toda entrada de dados > Sanitize Como evitar?
  • 32. A2 - Quebra de Autenticação e Gerenciamento de Sessão
  • 35. A1 - Injeção Exemplos de Cenários de Ataque

Notas do Editor

  1. Cada um desses caminhos representa um risco que pode, ou não, ser grave o suficiente para justificar a sua atenção.
  2. As equipes devem treinadas para desenvolver aplicações confiáveis.
  3. “OUOSP” Todos as ferramentas, documentos, fóruns e capítulos do OWASP são grátis e abertos a todos os interessados em aperfeiçoar a segurança em aplicações.
  4. Para cada um desses riscos, fornecem informações genéricas sobre a probabilidade de ocorrência e impacto técnico usando um esquema simples de classificação, que se baseia na metodologia de avaliação de riscos da OWASP (OWASP Risk Rating Methodology).
  5. Aplicações web frequentemente redirecionam e encaminham usuários para outras páginas e sites, e usam dados não confiáveis para determinar as páginas de destino. Sem uma validação adequada, os atacantes podem redirecionar as vítimas para sites de phishing ou malware, ou usar encaminhamentos para acessar páginas não autorizadas.
  6. Se a vítima visitar qualquer um dos sites do atacante enquanto estiver autenticado em exemplo.com, essas requisições forjadas irão incluir automaticamente informações de sessão do usuário, autorizando o pedido do atacante.
  7. Se um usuário autenticado, não administrador, tem permissão para acessar a página “admin_getappInfo”, isso também é uma falha, e pode levar o atacante para mais páginas de administração inadequadamente protegidas.
  8. Muitas das aplicações web não mostram links e botões para funções não autorizadas, mas esse "controle de acesso na camada de apresentação" na verdade não fornece proteção. Você também deve implementar verificações na lógica do controlador ou do negócio.
  9. Exemplo aeroporto man in the middle
  10. Não alterar nomes default de aplicações instaladas /admin admin !@#Mudar
  11. Exemplo de endereços de URL para imagens/arquivos Códigos sequenciais em URL
  12. Exemplo de endereços de URL para imagens/arquivos Códigos sequenciais em URL
  13. Evitar? Validar acesso
  14. Isso causa o envio do ID de sessão da vítima para o site do atacante, permitindo que o atacante sequestre a sessão atual do usuário. Note que o atacante também pode usar o XSS para anular qualquer defesa automática de CSRF que a aplicação possa empregar.
  15. A opção apropriada é filtrar adequadamente todos os dados não-confiáveis com base no contexto HTML (corpo, atributo, JavaScript, CSS ou URL) no qual os dados serão colocados. Veja o OWASP XSS Prevention Cheat Sheet para detalhes sobre os requisitos das técnicas de filtro de dados. 2. “Lista branca" ou validação de entrada positiva também é recomendada pois ajuda a proteger contra XSS, mas não é uma defesa completa, já que muitas aplicações requerem caracteres especiais em sua entrada. Tal validação deve, tanto quanto possível, validar o tamanho, caracteres, formato, e as regras de negócio sobre os dados antes de aceitar a entrada. 3. Para conteúdo rico considere bibliotecas de auto-sanitização como OWASP's AntiSamy ou o Java HTML Sanitizer Project. 4. Considere a Content Security Policy (CSP) para se defender contra XSS em todo o seu site