Imagine que você tinha um site como o Twitter simplificado, hospedado em a.com. Os usuários conectados podem inserir algum texto (um tweet) em um formulário que está sendo enviado ao servidor como uma solicitação POST e publicado quando eles pressionam o botão de envio. No servidor, o usuário é identificado por um cookie contendo seu ID de sessão exclusivo, para que seu servidor saiba quem postou o Tweet.
O formulário pode ser tão simples quanto isso:
<form action="http://a.com/tweet" method="POST">
<input type="text" name="tweet">
<input type="submit">
</form>
Agora imagine que um bandido copia e cola esse formulário em seu site malicioso, digamos b.com. O formulário ainda funcionaria. Desde que um usuário esteja conectado ao seu Twitter (ou seja, ele tenha um cookie de sessão válido para a.com), a solicitação POST será enviada para
http://a.com/tweet e processada como de costume quando o usuário clicar no botão Enviar.
Até agora, isso não é um grande problema, desde que o usuário seja informado sobre o que exatamente o formulário faz, mas e se nosso bandido alterar o formulário da seguinte maneira:
<form action="https://example.com/tweet" method="POST">
<input type="hidden" name="tweet" value="Buy great products at http://b.com/#iambad">
<input type="submit" value="Click to win!">
</form>
Agora, se um de seus usuários aparecer no site do bandido e clicar no botão "Clique para vencer!" , o formulário é enviado ao seu site, o usuário é identificado corretamente pelo ID da sessão no cookie e o Tweet oculto é publicado.
Se nosso bandido fosse ainda pior, ele faria o usuário inocente enviar este formulário assim que abrir sua página da Web usando JavaScript, talvez até completamente escondido em um iframe invisível. Basicamente, isso é falsificação de solicitação entre sites.
Um formulário pode ser facilmente enviado de qualquer lugar para qualquer lugar. Geralmente, esse é um recurso comum, mas há muitos outros casos em que é importante permitir apenas o envio de um formulário do domínio ao qual ele pertence.
As coisas ficam ainda piores se seu aplicativo da web não faz distinção entre solicitações POST e GET (por exemplo, no PHP usando $ _REQUEST em vez de $ _POST). Não faça isso! Os pedidos de alteração de dados podem ser enviados tão facilmente quanto<img src="http://a.com/tweet?tweet=This+is+really+bad"> , incorporados a um site mal-intencionado ou até a um email.
Como garantir que um formulário só possa ser enviado em meu próprio site? É aqui que o token CSRF entra. Um token CSRF é uma sequência aleatória e difícil de adivinhar. Em uma página com um formulário que você deseja proteger, o servidor geraria uma sequência aleatória, o token CSRF, o adicionaria ao formulário como um campo oculto e também se lembraria de alguma forma, seja armazenando-o na sessão ou definindo um cookie contendo o valor Agora, o formulário ficaria assim:
<form action="https://example.com/tweet" method="POST">
<input type="hidden" name="csrf-token" value="nc98P987bcpncYhoadjoiydc9ajDlcn">
<input type="text" name="tweet">
<input type="submit">
</form>
Quando o usuário envia o formulário, o servidor simplesmente precisa comparar o valor do campo publicado csrf-token (o nome não importa) com o token CSRF lembrado pelo servidor. Se as duas strings forem iguais, o servidor poderá continuar processando o formulário. Caso contrário, o servidor deve parar imediatamente de processar o formulário e responder com um erro.
Por que isso funciona? Há várias razões pelas quais o bandido do nosso exemplo acima não consegue obter o token CSRF:
Copiar o código-fonte estático da nossa página para um site diferente seria inútil, porque o valor do campo oculto muda com cada usuário. Sem que o site do bandido conheça o token CSRF do usuário atual, seu servidor sempre rejeitará a solicitação POST.
Como a página maliciosa do bandido é carregada pelo navegador do usuário de um domínio diferente (b.com em vez de a.com), o bandido não tem chance de codificar um JavaScript, que carrega o conteúdo e, portanto, o token CSRF atual do usuário de seu site. Isso ocorre porque os navegadores da web não permitem solicitações AJAX entre domínios por padrão.
O bandido também não pode acessar o cookie definido pelo seu servidor, porque os domínios não coincidem.
Quando devo me proteger contra a falsificação de solicitações entre sites? Se você pode garantir que não combina GET, POST e outros métodos de solicitação, conforme descrito acima, um bom começo seria proteger todas as solicitações POST por padrão.
Você não precisa proteger solicitações PUT e DELETE, porque, como explicado acima, um formulário HTML padrão não pode ser enviado por um navegador usando esses métodos.
Por outro lado, o JavaScript pode realmente fazer outros tipos de solicitações, por exemplo, usando a função $ .ajax () do jQuery, mas lembre-se de que, para que as solicitações AJAX funcionem, os domínios devem corresponder (desde que você não configure explicitamente o servidor da Web) .
Isso significa que, muitas vezes, você nem precisa adicionar um token CSRF às solicitações AJAX, mesmo que sejam solicitações POST, mas você deve evitar a verificação CSRF em seu aplicativo da Web se a solicitação POST for realmente uma solicitação. Solicitação AJAX. Você pode fazer isso procurando a presença de um cabeçalho como X-Requested-With, que as solicitações do AJAX geralmente incluem. Você também pode definir outro cabeçalho personalizado e verificar sua presença no lado do servidor. Isso é seguro, porque um navegador não adiciona cabeçalhos personalizados a um envio regular de formulário HTML (veja acima), portanto, o Sr. Bad Guy não pode simular esse comportamento com um formulário.
Se você tiver dúvidas sobre solicitações AJAX, porque, por algum motivo, não pode verificar um cabeçalho como X-Requested-With, basta passar o token CSRF gerado para o seu JavaScript e adicionar o token à solicitação AJAX. Existem várias maneiras de fazer isso; adicione-o à carga útil como faria um formulário HTML comum ou adicione um cabeçalho personalizado à solicitação AJAX. Desde que o servidor saiba onde procurá-lo em uma solicitação recebida e possa compará-lo com o valor original que lembra da sessão ou cookie, você será classificado.