Följ dessa steg för att dra nytta av CSRF-skydd i dina vyer:
\nCSRF-mellanvaran är aktiverad som standard i inställningen MIDDLEWARE. Om du åsidosätter den inställningen, kom ihåg att 'django.middleware.csrf.CsrfViewMiddleware' bör komma före alla view middleware som antar att CSRF-attacker har hanterats.
Om du inaktiverar det, vilket inte rekommenderas, kan du använda csrf_protect() på särskilda vyer som du vill skydda (se nedan).
I alla mallar som använder ett POST-formulär ska du använda taggen csrf_token inuti elementet <form> om formuläret är för en intern URL, t.ex:
<form method="post">{% csrf_token %}\nDetta bör inte göras för POST-formulär som riktar sig till externa webbadresser, eftersom det skulle leda till att CSRF-token läcker ut, vilket leder till en sårbarhet.
\nI motsvarande vyfunktioner ska du se till att RequestContext används för att rendera svaret så att {% csrf_token %} fungerar korrekt. Om du använder render()-funktionen, generiska vyer eller Contrib-appar, är du redan täckt eftersom dessa alla använder RequestContext.
Även om ovanstående metod kan användas för AJAX POST-begäranden har den vissa nackdelar: du måste komma ihåg att skicka CSRF-token som POST-data vid varje POST-begäran. Av denna anledning finns det en alternativ metod: på varje XMLHttpRequest, ställ in en anpassad X-CSRFToken header (som anges av inställningen CSRF_HEADER_NAME) till värdet av CSRF-token. Detta är ofta enklare eftersom många JavaScript-ramverk tillhandahåller hooks som gör det möjligt att ställa in rubriker vid varje begäran.
Först måste du hämta CSRF-token. Hur du gör det beror på om inställningarna CSRF_USE_SESSIONS och CSRF_COOKIE_HTTPONLY är aktiverade eller inte.
Slutligen måste du ställa in rubriken på din AJAX-begäran. Använda API:et fetch():
\nconst request = new Request(\n /* URL */,\n {\n method: 'POST',\n headers: {'X-CSRFToken': csrftoken},\n mode: 'same-origin' // Do not send CSRF token to another domain.\n }\n);\nfetch(request).then(function(response) {\n // ...\n});\nDjangos Jinja2 mallbackend lägger till {{ csrf_input }} i kontexten för alla mallar, vilket motsvarar {% csrf_token %} i Djangos mallspråk. Till exempel:
<form method="post">{{ csrf_input }}\nI stället för att lägga till CsrfViewMiddleware som ett allmänt skydd kan du använda csrf_protect()-dekoratorn, som har exakt samma funktionalitet, på särskilda vyer som behöver skyddet. Den måste användas både på vyer som infogar CSRF-token i utdata och på de som accepterar POST-formulärdata. (Dessa är ofta samma vyfunktion, men inte alltid).
Det är inte att rekommendera att använda dekoratorn ensam, eftersom det finns ett säkerhetshål om man glömmer att använda den. Strategin med att använda båda är bra och medför minimalt med overhead.
\nSom standard skickas ett ”403 Forbidden”-svar till användaren om en inkommande begäran inte klarar de kontroller som utförs av CsrfViewMiddleware. Detta bör vanligtvis bara ses när det finns en äkta Cross Site Request Forgery, eller när CSRF-token på grund av ett programmeringsfel inte har inkluderats i ett POST-formulär.
Felsidan är dock inte särskilt användarvänlig, så du kanske vill skapa en egen vy för att hantera detta tillstånd. Detta gör du genom att ange inställningen CSRF_FAILURE_VIEW.
CSRF-misslyckanden loggas som varningar till loggern django.security.csrf.
\nOm malltaggen csrf_token används av en mall (eller om funktionen get_token anropas på något annat sätt), kommer CsrfViewMiddleware att lägga till en cookie och en Vary: Cookie till svaret. Detta innebär att mellanvaran kommer att fungera bra tillsammans med cache-mellanvaran om den används enligt instruktionerna (UpdateCacheMiddleware går före alla andra mellanvaror).
Men om du använder cachedekoratorer på enskilda vyer kommer CSRF-mellanvaran ännu inte att ha kunnat ställa in Vary-huvudet eller CSRF-cookien, och svaret kommer att cachas utan någon av dem. I det här fallet bör du på alla vyer som kräver att en CSRF-token infogas använda django.views.decorators.csrf.csrf_protect()-dekoratorn först:
from django.views.decorators.cache import cache_page\nfrom django.views.decorators.csrf import csrf_protect\n\n\n@cache_page(60 * 15)\n@csrf_protect\ndef my_view(request): ...\nOm du använder klassbaserade vyer kan du läsa Dekorera klassbaserade vyer.
\nCsrfViewMiddleware kommer vanligtvis att vara ett stort hinder för att testa vyfunktioner, på grund av behovet av CSRF-token som måste skickas med varje POST-begäran. Av denna anledning har Djangos HTTP-klient för tester modifierats för att ställa in en flagga på förfrågningar som slappnar av mellanvaran och dekoratorn csrf_protect så att de inte längre avvisar förfrågningar. I alla andra avseenden (t.ex. skicka cookies etc.) beter de sig likadant.
Om du av någon anledning vill att testklienten ska utföra CSRF-kontroller kan du skapa en instans av testklienten som verkställer CSRF-kontroller:
\n>>> from django.test import Client\n>>> csrf_client = Client(enforce_csrf_checks=True)\nVissa vyer kan ha ovanliga krav som innebär att de inte passar in i det normala mönstret som beskrivs här. Ett antal verktyg kan vara användbara i dessa situationer. De scenarier där de kan behövas beskrivs i följande avsnitt.
\nDe flesta visningar kräver CSRF-skydd, men några gör det inte.
\nLösning: Istället för att inaktivera middleware och tillämpa csrf_protect på alla vyer som behöver det, aktivera middleware och använd csrf_exempt().
CsrfViewMiddleware.process_view() inte användsLink to this heading#Det finns fall där CsrfViewMiddleware.process_view kanske inte har körts innan din vy körs - 404- och 500-hanterare, till exempel - men du behöver fortfarande CSRF-token i ett formulär.
Lösning: använd requires_csrf_token()
Det kan finnas vissa vyer som är oskyddade och har undantagits med csrf_exempt, men som ändå måste innehålla CSRF-token.
Lösning: använd csrf_exempt() följt av requires_csrf_token(). (dvs. requires_csrf_token bör vara den innersta dekoratorn).
En vy behöver CSRF-skydd endast under en uppsättning villkor, och får inte ha det under resten av tiden.
\nLösning: använd csrf_exempt() för hela vyfunktionen, och csrf_protect() för sökvägen inom den som behöver skyddas. Exempel:
from django.views.decorators.csrf import csrf_exempt, csrf_protect\n\n\n@csrf_exempt\ndef my_view(request):\n @csrf_protect\n def protected_path(request):\n do_something()\n\n if some_condition():\n return protected_path(request)\n else:\n do_something_else()\nEn sida gör en POST-begäran via AJAX, och sidan har inte ett HTML-formulär med en csrf_token som skulle göra att den nödvändiga CSRF-cookien skickas.
Lösning: använd ensure_csrf_cookie() på den vy som skickar sidan.
Eftersom det är möjligt för utvecklaren att stänga av CsrfViewMiddleware använder alla relevanta vyer i Contrib-appar csrf_protect-dekoratorn för att garantera säkerheten för dessa applikationer mot CSRF. Det rekommenderas att utvecklare av andra återanvändbara appar som vill ha samma garantier också använder dekoratorn csrf_protect på sina vyer.