Proteção Cross Site Request Forgery

A classe CsrfMiddleware provê uma proteção fácil de usar contra Requisições Cross Site falsas. Esse tipo de ataque ocorre quando um website malicioso cria um link ou um botão de formulário que é destinado a executar alguma ação sobre seu site, usando credenciais de um usuário logado que pode ser enganado ao clicar em um link no seu navegador.

A primeira defesa contra ataques CSRF é assegurar que requisições GET são livres de efeitos colaterais. Requisições POST podem então ser protegidas por este middleware, adicionando-o em sua lista de middlewares instalados.

Como usá-lo

Adicione o middleware 'django.contrib.csrf.middleware.CsrfMiddleware' em sua lista de classes middleware, MIDDLEWARE_CLASSES. Ele necessita processar a resposta depois do SessionMiddleware, portanto deve vir antes dele na lista. Ele também deve processar a resposta antes de coisas como compressão, que ocorrerá com a resposta, logo deve vir depois do GZipMiddleware na lista.

Como ele funciona

CsrfMiddleware faz duas coisas:

  1. Modifica requisições de saída adicionando um campo hidden para todo formulário ‘POST’, com o nome ‘csrfmiddlewaretoken’ e um valor que é um hash composto pelo ID da sessão mais um secret. Se não houver um ID de sessão configurado, esta modificação da resposta não será feita. Assim há muito pouca perda de performance para essas requisições que não possuem uma sessão.
  2. Em todos as requisições POST de entrada que tiverem um cookie de sessão configurado, ele checa se o ‘csrfmiddlewaretoken’ está presente e correto. Se não estiver, o usuário receberá um erro 403.

Isso assegura que somente formulários originários de seu website podem ser usados para enviar dados de volta.

Deliberadamente somente são alvos de requisições os POSTS HTTP (e os formulários POST correspondentes). Requisições GET não costumam representar um perigo em potencial (veja 9.1.1 Métodos Seguros, HTTP 1.1, RFC 2616), logo um ataque CSRF com uma requisição GET costuma ser inofensivo.

Requisições POST que não são acompanhadas por um cookie de sessão não estão protegidas, mas elas não precisam ser protegidas, uma vez que o website agressor poderia fazer este tipo de requisição de qualquer maneira.

O Content-Type é checado antes de modificar a resposta, e somente páginas que são servidas como ‘text/html’ ou ‘application/xml+xhtml’ são modificadas.

Limitações

O CsrfMiddleware requer o framework de sessões do Django para funcionar. Se você tem um sistema customizado de autenticação que manualmente configura os cookies, ele não irá ajudá-lo.

Se sua aplicação cria páginas HTML e formulários de alguma forma incomum, (ex: ela envia fragmentos de páginas HTML em chamadas document.write de JavaScript), você pode pular o filtro que adiciona o campo hidden no formulário, caso este no qual a submissão do formulário irá sempre falhar. Pode ser ainda possível usar o middleware, desde que você consiga encontrar uma maneira de obter o token CSRF e assegurar-se de que ele está incluído quando os seus formulários forem enviados.