Baixar para ler offline
![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](https://image.slidesharecdn.com/falsificaodesolicitaoentresites-csrf-141121165036-conversion-gate01/75/Falsificacao-de-solicitacao-entre-sites-csrf-html-6-2048.jpg)
Carregado porRafael Tavares
Falsificação de solicitação entre sites csrf.html
Este documento discute o CSRF (Cross-Site Request Forgery), um tipo de ataque que explora a confiança que sites têm no navegador do usuário para executar ações não autorizadas. O documento explica o conceito, como funciona, exemplos de ataques CSRF e soluções como a política de mesma origem e gerar tokens CSRF para validar requisições.
Falsificação de solicitação entre sites csrf.html
- 1. Falsificação de solicitaçãoentre sites - CSRF CROSS-SITE REQUEST FORGERY RAFAEL TAVARES ANDRADE TOLEDO
- 2. Agenda Historia Conceito Funcionamento Possibilidades de Ataques O Ataque – Exemplo Politica de mesma origem – Same-origin policy A Solução Referências
- 3. Historia Primeiroscasos 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. Conceito OCross-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.
- 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. 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. 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. 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. 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. 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.
- 13. Solução Podemosacrescentar 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. Funcionamento – Politicade 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. Funcionamento – Politicade 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.
- 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
Notas do Editor
- #7 Esta política também se aplica a XMLHttpRequests a menos que o servidor forneça um cabeçalho Access-Control-Allow-Origin (CORS)
- #11 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.
- #12 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.
- #13 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.
- #14 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.
- #16 Netscape Navigator 2 em 1995.