Falsificação de 
solicitação entre 
sites - CSRF 
CROSS-SITE REQUEST FORGERY 
RAFAEL TAVARES ANDRADE TOLEDO
Agenda 
 Historia 
 Conceito 
 Funcionamento 
 Possibilidades de Ataques 
 O Ataque – Exemplo 
 Politica de mesma or...
Historia 
 Primeiros casos 2001. 
 Cerca de 18 milhões de usuários do eBay na Coréia perdeu a 
informação pessoais em fe...
Conceito 
 O Cross-site request forgery é um tipo de exploração 
maliciosa de um website pelo qual comandos não 
autoriza...
Funcionamento – CSRF
Possibilidades de Ataques 
 Tags 
<img src=“https://bank.com/fn?param=1”> 
<iframe src=“https://bank.com/fn?param=1”> 
<s...
O Ataque 
 Alice deseja transferir R$ 100,00 a João usando banco.com.br. 
O pedido gerado por Alice será semelhante ao se...
O Ataque 
 Maria decide agora para explorar esta vulnerabilidade de 
aplicações web usando Alice como sua vítima. Maria p...
O Ataque 
 Supondo que Alice esta autenticada com a aplicação, quando 
ela clica no link, a transferência de R$ 100.000 p...
O Ataque 
 Se essa tag de imagem for incluída no e-mail, Alice só vê uma 
pequena caixa que indica que o navegador não po...
A Solução 
 A solução para o problema de CSRF é gerar uma chave única quando o 
usuário visita a página com o formulário....
Solução
Solução 
 Podemos acrescentar um nível adicional de segurança, certificando-se 
o usuário veio a partir da página que con...
Funcionamento – Politica de 
mesma origem 
 A política de mesma origem restringe como um documento ou script 
carregado a...
Funcionamento – Politica de 
mesma origem 
 Mozilla considera duas páginas para ter a mesma origem, se o protocolo, porta...
Solução 
 RequestPolicy
Referências 
 https://www.w3.org/Security/wiki/Same_Origin_Policy 
 http://www.owasp.org/index.php/Cross-Site_Request_Fo...
Próximos SlideShares
Carregando em…5
×

Falsificação de solicitação entre sites csrf.html

528 visualizações

Publicada em

Apresentação da disciplina de Segurança de Aplicações WEB

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

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
528
No SlideShare
0
A partir de incorporações
0
Número de incorporações
218
Ações
Compartilhamentos
0
Downloads
5
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide
  • Esta política também se aplica a XMLHttpRequests a menos que o servidor forneça um cabeçalho Access-Control-Allow-Origin (CORS)
  • Este exemplo, pode ocorrer em qualquer aplicação que não possua tratamento no controle de formulários e/ou outros meios de entrada de dados.
  • Este exemplo, pode ocorrer em qualquer aplicação que não possua tratamento no controle de formulários e/ou outros meios de entrada de dados.
  • Este exemplo, pode ocorrer em qualquer aplicação que não possua tratamento no controle de formulários e/ou outros meios de entrada de dados.
  • Este exemplo, pode ocorrer em qualquer aplicação que não possua tratamento no controle de formulários e/ou outros meios de entrada de dados.
  •  Netscape Navigator 2 em 1995.
  • Falsificação de solicitação entre sites csrf.html

    1. 1. Falsificação de solicitação entre sites - CSRF CROSS-SITE REQUEST FORGERY RAFAEL TAVARES ANDRADE TOLEDO
    2. 2. Agenda  Historia  Conceito  Funcionamento  Possibilidades de Ataques  O Ataque – Exemplo  Politica de mesma origem – Same-origin policy  A Solução  Referências
    3. 3. Historia  Primeiros casos 2001.  Cerca de 18 milhões de usuários do eBay na Coréia perdeu a informação pessoais em fevereiro de 2008.  Os clientes de um banco em México foram atacados no início de 2008 com uma tag de imagem em e-mail. O link da tag de imagem mudou a entrada DNS para o banco em seu roteador ADSL para apontar para um site malicioso se passando pelo banco
    4. 4. Conceito  O Cross-site request forgery é um tipo de exploração maliciosa de um website pelo qual comandos não autorizados são transmitidos para um site malicioso. Ao contrário do XSS, que explora a confiança de um usuário para um site particular, o CSRF explora a confiança que um site tem no navegador do usuário.
    5. 5. Funcionamento – CSRF
    6. 6. Possibilidades de Ataques  Tags <img src=“https://bank.com/fn?param=1”> <iframe src=“https://bank.com/fn?param=1”> <script src=“https://bank.com/fn?param=1”>  Posts automáticos em forms <body onload="document.forms[0].submit()"> <form method="POST" action=“https://bank.com/fn”> <input type="hidden" name="sp" value="8109"/> </form>  XmlHttpRequest  Sujeito a politica de mesma origem
    7. 7. O Ataque  Alice deseja transferir R$ 100,00 a João usando banco.com.br. O pedido gerado por Alice será semelhante ao seguinte:  No entanto, percebe que Maria da mesma aplicação web irá executar a mesma transferência usando parâmetros de URL da seguinte forma:
    8. 8. O Ataque  Maria decide agora para explorar esta vulnerabilidade de aplicações web usando Alice como sua vítima. Maria primeiro constrói a seguinte URL, que vai transferir R$ 100.000,00 da conta de Alice à sua conta:  Agora que seu pedido mal-intencionado é gerado, Maria tem truque para apresentar o pedido. O método mais básico é o de enviar um e-mail HTML para Alice contendo o seguinte:
    9. 9. O Ataque  Supondo que Alice esta autenticada com a aplicação, quando ela clica no link, a transferência de R$ 100.000 para a conta de Maria irá ocorrer.  No entanto, Maria percebe que se Alice clica no link, em seguida, Alice vai notar que a transferência ocorreu.  Por isso, Maria decide esconder o ataque em uma imagem de zero bytes:
    10. 10. O Ataque  Se essa tag de imagem for incluída no e-mail, Alice só vê uma pequena caixa que indica que o navegador não pode processar a imagem. No entanto, o navegador continua a enviar a solicitação para banco.com.br sem qualquer indicação visual de que atransferência tenha ocorrido.
    11. 11. A Solução  A solução para o problema de CSRF é gerar uma chave única quando o usuário visita a página com o formulário.  Vamos definir esta chave na $_SESSION, bem como um campo hidden no formulário.  Quando o formulário for enviado, vamos verificar a chave armazenada na sessão e a chave enviada pelo formulário. Se eles são os mesmos então nós sabemos que o usuário submeteu nosso formulário. Se eles não são iguais (ou a $_SESSION está vazia), então sabemos que algo nocivo está acontecendo e nós podemos seguramente redirecionar o usuário (e não tomar nenhuma ação).
    12. 12. Solução
    13. 13. Solução  Podemos acrescentar um nível adicional de segurança, certificando-se o usuário veio a partir da página que contém o formulário.
    14. 14. Funcionamento – Politica de mesma origem  A política de mesma origem restringe como um documento ou script carregado a partir de uma origem pode interagir com um recurso de outra origem.
    15. 15. Funcionamento – Politica de mesma origem  Mozilla considera duas páginas para ter a mesma origem, se o protocolo, porta (se informado), e o host/domínio são os mesmos para ambas as páginas. Para ilustrar, esta tabela dá exemplos de comparações origem para o URL http://store.company.com/dir/page.html .
    16. 16. Solução  RequestPolicy
    17. 17. Referências  https://www.w3.org/Security/wiki/Same_Origin_Policy  http://www.owasp.org/index.php/Cross-Site_Request_Forgery  http://www.cgisecurity.com/articles/csrf-faq.shtml  http://www.darkreading.com/document.asp?doc_id=107651&WT.svl =news1_2 HTTP://RAFAELTAVARES.CO/APRESENTACOES

    ×