Django – Vietato (CSRF cookie non impostato.)

Ho un sito web Django con traffico medio (circa 4000/5000 visite al giorno). Oggi ho configurato il “LOGGING” opzione settings.py per inviare una e-mail con “Info” livello, basta controllare se tutto era ok…

Ci fu la mia sorpresa, ricevo il seguente errore:
[Django] ATTENZIONE (IP ESTERNO): non consentito (TIPO di cookie non impostato.)

No stack trace available

<WSGIRequest
path:/cadastro/usuario/,
GET:<QueryDict: {}>,
POST:<QueryDict: {**xxxxxxx (some varibles....) and**: u'csrfmiddlewaretoken': [u'4wqRKQXZsTmXJaOkCsGobWyG1rzihc8x'], }>,
COOKIES:{},
META:{'CONTENT_LENGTH': '381',
 'CONTENT_TYPE': 'application/x-www-form-urlencoded',
 'CSRF_COOKIE': 'qzc4i7JdHoQLJ8N5aI9MTlamOZMOKmP0',
 'DOCUMENT_ROOT': '/opt/nginx/html',
 'HTTP_ACCEPT': 'text/html, application/xhtml+xml, */*',
 'HTTP_ACCEPT_ENCODING': 'gzip, deflate',
 'HTTP_ACCEPT_LANGUAGE': 'pt-BR',
 'HTTP_CACHE_CONTROL': 'no-cache',
 'HTTP_CONNECTION': 'Keep-Alive',
 'HTTP_CONTENT_LENGTH': '381',
 'HTTP_CONTENT_TYPE': 'application/x-www-form-urlencoded',
 'HTTP_HOST': 'xxxxxx',
 'HTTP_REFERER': 'http://xxxx/y/z',
 'HTTP_USER_AGENT': 'Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)',
 'PATH_INFO': u'/y/z',
 'QUERY_STRING': '',
 'REMOTE_ADDR': '187.27.35.123',
 'REMOTE_PORT': '54221',
 'REQUEST_METHOD': 'POST',
 'REQUEST_URI': 'y/z',
 'SCRIPT_NAME': u'',
 'SERVER_NAME': 'xxxxxxx',
 'SERVER_PORT': '80',
 'SERVER_PROTOCOL': 'HTTP/1.1',
 'uwsgi.version': '0.9.6.5',
 'wsgi.errors': <open file 'wsgi_input', mode 'w' at 0xa126338>,
 'wsgi.file_wrapper': <built-in function uwsgi_sendfile>,
 'wsgi.input': <open file 'wsgi_input', mode 'r' at 0xa126a70>,


 'wsgi.multiprocess': True,
 'wsgi.multithread': False,
 'wsgi.run_once': False,
 'wsgi.url_scheme': 'http',
 'wsgi.version': (1, 0)}>

Ho provato a riprodurre questo errore, ma non ho potuto. I test su Firefox e Chrome, puliti tutti i cookie… Tutto è andato bene. Ma ottengo questo errore una dozzina di tempo, sempre con IP diversi, quindi suppongo che non è un attacco… Tutta la mia forma è {% funzioni csrf_token %} e django.middleware.csrf.CsrfViewMiddleware è configurato su MIDDLEWARE_CLASSES.

Il messaggio di log di cui sopra è molto chiaro che CSRF_COOKIE non è vuoto. Sto usando Django 1.4.

[AGGIORNATO]
Penso che la tesi di utenti non sono abilitati i cookie…
Allora… Il problema è: Come utilizzare CSRF con utenti che non sono abilitati i cookie?

Potrebbe essere che il client non ha i cookie abilitati? Forse è un crawler o casuale tipo di client.
Ciao Jdi, POST variabile vedo che è un utente valido (non un crawler). Se il client non hanno cookie attivare il “CSRF_COOKIE” wouldnt essere vuoto?
Jdi, ho appena fatto questa prova qui… ho rimosso CSRF_COOKIE con firecookie e mi esce l’errore. Io non sono sicuro se questo è il problema perché io sono sempre un sacco di errori, ma sapete come posso avvisare l’utente di abilitare i cookie?
Forse un test javascript? forums.asp.net/t/1149145.aspx/1
Sto provando a cercare qualche altra soluzione, qualcuno ha un’idea?

OriginaleL’autore Thomas | 2012-04-22

One Reply
  1. 2

    Come avevo accennato nel mio primo commento, vedrai che errore quando 403 è alzato a causa di un TIPO di errore.

    Non è necessario preoccuparsi di cercare di gestire la protezione CSRF contro gli utenti senza i cookie abilitati. La natura stessa del TIPO di attacco richiede l’uso di cookie del browser. Se non vengono utilizzati, il TIPO protetto richiesta avrà esito negativo (come avete visto). Così, sono ancora protetti.

    Django consente di impostare una visualizzazione specifica per l’utilizzo per il cliente in caso di un TIPO di errore: https://docs.djangoproject.com/en/dev/ref/settings/#std%3asetting-CSRF_FAILURE_VIEW

    Davvero, non dovrete fare altro che notare che ci sono richieste che stanno cercando di POST al server non valido.

    OriginaleL’autore jdi

Lascia un commento