Detta dokument är en översikt över Djangos säkerhetsfunktioner. Det innehåller råd om hur du säkrar en Djangodriven webbplats.
\nDen gyllene regeln för säkerhet i webbapplikationer är att aldrig lita på användarkontrollerade data. Därför bör alla användarinmatningar rensas innan de används i din applikation. Se formulardokumentation för detaljer om validering av användarinmatningar i Django.
\nXSS-attacker gör det möjligt för en användare att injicera skript på klientsidan i andra användares webbläsare. Detta görs vanligtvis genom att lagra de skadliga skripten i en databas där de kan hämtas och visas för andra användare, eller genom att få användarna att klicka på en länk som gör att angriparens JavaScript körs av användarens webbläsare. XSS-attacker kan dock komma från vilken otillförlitlig datakälla som helst, t.ex. cookies eller webbtjänster, om datan inte rensas tillräckligt innan den inkluderas i en sida.
\nGenom att använda Django-mallar skyddar du dig mot de flesta XSS-attacker. Det är dock viktigt att förstå vilka skydd det ger och dess begränsningar.
\nDjango templates escape specifika tecken som är särskilt farliga för HTML. Även om detta skyddar användare från de flesta skadliga inmatningar, är det inte helt idiotsäkert. Till exempel kommer det inte att skydda följande:
\n<style class={{ var }}>...</style>\nOm var är satt till 'class1 onmouseover=javascript:func()', kan detta resultera i obehörig JavaScript-körning, beroende på hur webbläsaren renderar imperfekt HTML. (Att citera attributvärdet skulle lösa detta fall.)
Det är också viktigt att vara särskilt försiktig när man använder is_safe med anpassade malltaggar, malltaggen safe, mark_safe och när autoescape är avstängt.
Om du använder mallsystemet för att skriva ut något annat än HTML kan det dessutom finnas helt separata tecken och ord som kräver escaping.
\nDu bör också vara mycket försiktig när du lagrar HTML i databasen, särskilt när denna HTML hämtas och visas.
\nCSRF-attacker gör det möjligt för en illasinnad användare att utföra åtgärder med hjälp av en annan användares inloggningsuppgifter utan den användarens vetskap eller samtycke.
\nDjango har ett inbyggt skydd mot de flesta typer av CSRF-attacker, förutsatt att du har aktiverat och använt det där det är lämpligt. Men som med alla begränsningstekniker finns det begränsningar. Det är till exempel möjligt att inaktivera CSRF-modulen globalt eller för vissa vyer. Du bör bara göra detta om du vet vad du gör. Det finns andra begränsningar om din webbplats har underdomäner som ligger utanför din kontroll.
\nCSRF-skyddet fungerar genom att kontrollera om det finns en hemlig kod i varje POST-begäran. Detta säkerställer att en illvillig användare inte kan ”spela upp” en POST-begäran till din webbplats och få en annan inloggad användare att omedvetet skicka in formuläret. Den illvilliga användaren måste känna till den hemliga koden, som är användarspecifik (med hjälp av en cookie).
\nVid distribution med HTTPS kommer CsrfViewMiddleware att kontrollera att HTTP-referer-headern är inställd på en URL med samma ursprung (inklusive underdomän och port). Eftersom HTTPS ger ytterligare säkerhet är det absolut nödvändigt att se till att anslutningar använder HTTPS där det är tillgängligt genom att vidarebefordra osäkra anslutningsförfrågningar och använda HSTS för webbläsare som stöds.
Var mycket försiktig med att markera vyer med dekoratorn csrf_exempt om det inte är absolut nödvändigt.
SQL-injektion är en typ av attack där en illasinnad användare kan köra godtycklig SQL-kod i en databas. Detta kan resultera i att poster raderas eller att data läcker ut.
\nDjangos querysets är skyddade från SQL-injektion eftersom deras frågor är konstruerade med hjälp av query parameterization. En frågas SQL-kod definieras separat från frågans parametrar. Eftersom parametrar kan vara användartillhandahållna och därför osäkra, escapas de av den underliggande databasdrivrutinen.
\nDjango ger också utvecklare möjlighet att skriva raw queries eller exekvera custom sql. Dessa funktioner bör användas sparsamt och du bör alltid vara noga med att korrekt escape alla parametrar som användaren kan kontrollera. Dessutom bör du vara försiktig när du använder extra() och RawSQL.
Clickjacking är en typ av attack där en skadlig webbplats kapslar in en annan webbplats i en ram. Denna attack kan leda till att en intet ont anande användare luras att utföra oavsiktliga åtgärder på målwebbplatsen.
\nDjango innehåller clickjacking protection i form av X-Frame-Options middleware som i en webbläsare med stöd kan förhindra att en webbplats återges inuti en ram. Det är möjligt att inaktivera skyddet per vy eller att konfigurera det exakta rubrikvärdet som skickas.
Middleware rekommenderas starkt för alla webbplatser som inte behöver ha sina sidor inbakade i en ram av webbplatser från tredje part, eller som bara behöver tillåta det för en liten del av webbplatsen.
\nDet är alltid bättre ur säkerhetssynpunkt att distribuera din webbplats bakom HTTPS. Utan detta är det möjligt för illvilliga nätverksanvändare att sniffa autentiseringsuppgifter eller annan information som överförs mellan klient och server, och i vissa fall - aktiva nätverksangripare - att ändra data som skickas i båda riktningarna.
\nOm du vill ha det skydd som HTTPS ger och har aktiverat det på din server, finns det några ytterligare steg som du kan behöva:
\nOm det behövs, ställ in SECURE_PROXY_SSL_HEADER, och se till att du har förstått varningarna där noggrant. Om du inte gör detta kan det leda till CSRF-sårbarheter, och om du inte gör det på rätt sätt kan det också vara farligt!
Sätt SECURE_SSL_REDIRECT till True, så att förfrågningar via HTTP omdirigeras till HTTPS.
Observera förbehållen under SECURE_PROXY_SSL_HEADER. När det gäller en omvänd proxy kan det vara enklare eller säkrare att konfigurera huvudwebbservern för att göra omdirigeringen till HTTPS.
Använd ”säkra” cookies.
\nOm en webbläsare initialt ansluter via HTTP, vilket är standard för de flesta webbläsare, är det möjligt att befintliga cookies läcker ut. Av denna anledning bör du ställa in inställningarna SESSION_COOKIE_SECURE och CSRF_COOKIE_SECURE till True. Detta instruerar webbläsaren att endast skicka dessa cookies via HTTPS-anslutningar. Observera att detta innebär att sessioner inte fungerar via HTTP och att CSRF-skyddet förhindrar att POST-data accepteras via HTTP (vilket är bra om du omdirigerar all HTTP-trafik till HTTPS).
Använd HTTP Strict Transport Security (HSTS)
\nHSTS är en HTTP-header som informerar en webbläsare om att alla framtida anslutningar till en viss webbplats alltid ska använda HTTPS. I kombination med omdirigering av förfrågningar via HTTP till HTTPS säkerställer detta att anslutningar alltid har den extra säkerheten hos SSL förutsatt att en lyckad anslutning har skett. HSTS kan antingen konfigureras med SECURE_HSTS_SECONDS, SECURE_HSTS_INCLUDE_SUBDOMAINS, och SECURE_HSTS_PRELOAD, eller på webbservern.
Django använder Host-rubriken som tillhandahålls av klienten för att konstruera webbadresser i vissa fall. Även om dessa värden rensas för att förhindra Cross Site Scripting-attacker, kan ett falskt Host-värde användas för Cross-Site Request Forgery, cacheförgiftningsattacker och förgiftning av länkar i e-postmeddelanden.
Eftersom även till synes säkra webbserverkonfigurationer är känsliga för falska Host-rubriker validerar Django Host-rubriker mot inställningen ALLOWED_HOSTS i metoden django.http.HttpRequest.get_host().
Denna validering gäller endast via get_host(); om din kod kommer åt Host-rubriken direkt från request.META kringgår du detta säkerhetsskydd.
För mer information se den fullständiga ALLOWED_HOSTS-dokumentationen.
Dessutom kräver Django att du uttryckligen aktiverar stöd för rubriken X-Forwarded-Host (via inställningen USE_X_FORWARDED_HOST) om din konfiguration kräver det.
Webbläsare använder rubriken Referer som ett sätt att skicka information till en webbplats om hur användarna kom dit. Genom att ställa in en Referrer Policy kan du hjälpa till att skydda dina användares integritet genom att begränsa under vilka omständigheter rubriken Referer ställs in. Se the referrer policy section of the security middleware reference för mer information.
Med rubriken COOP (Cross-origin Opener Policy) kan webbläsare isolera ett toppfönster från andra dokument genom att placera dem i en annan kontextgrupp så att de inte kan interagera direkt med toppfönstret. Om ett dokument som skyddas av COOP öppnar ett popup-fönster med ursprung i andra länder, kommer popup-fönstrets egenskap window.opener att vara null. COOP skyddar mot cross-origin-attacker. Se the cross-origin opener policy section of the security middleware reference för detaljer.
I likhet med CSRF limitations som kräver att en webbplats distribueras så att icke betrodda användare inte har tillgång till några underdomäner, har django.contrib.sessions också begränsningar. Se avsnittet om säkerhet i sessionens ämnesguide för mer information.
Om din webbplats accepterar filuppladdningar rekommenderas det starkt att du begränsar dessa uppladdningar i din webbserverkonfiguration till en rimlig storlek för att förhindra DOS-attacker (denial of service). I Apache kan detta enkelt ställas in med hjälp av direktivet LimitRequestBody.
Om du serverar dina egna statiska filer måste du se till att hanterare som Apaches mod_php, som skulle exekvera statiska filer som kod, är inaktiverade. Du vill inte att användare ska kunna exekvera godtycklig kod genom att ladda upp och begära en speciellt utformad fil.
Djangos hantering av uppladdning av media utgör vissa sårbarheter när media serveras på sätt som inte följer bästa praxis för säkerhet. Specifikt kan en HTML-fil laddas upp som en bild om filen innehåller en giltig PNG-header följt av skadlig HTML. Den här filen kommer att klara verifiering av det bibliotek som Django använder för ImageField bildbehandling (Pillow). När den här filen sedan visas för en användare kan den visas som HTML beroende på typ och konfiguration av din webbserver.
Det finns ingen skottsäker teknisk lösning på ramverksnivå för att på ett säkert sätt validera allt filinnehåll som laddas upp av användaren, men det finns några andra åtgärder du kan vidta för att mildra dessa attacker:
\nEn klass av attacker kan förhindras genom att alltid servera innehåll som laddats upp av användaren från en separat toppdomän eller andra nivådomän. Detta förhindrar alla typer av attacker som blockeras av ”samma-ursprungs-policy”-skydd, t.ex. cross site scripting. Om din webbplats till exempel körs på example.com, skulle du vilja servera uppladdat innehåll (inställningen MEDIA_URL) från något i stil med usercontent-example.com. Det är inte tillräckligt att servera innehåll från en underdomän som usercontent.example.com.
Utöver detta kan applikationer välja att definiera en lista över tillåtna filändelser för filer som laddas upp av användaren och konfigurera webbservern så att den endast hanterar sådana filer.
Även om Django ger ett bra säkerhetsskydd direkt från start är det fortfarande viktigt att distribuera din applikation på rätt sätt och dra nytta av säkerhetsskyddet för webbservern, operativsystemet och andra komponenter.
\nSe till att din Python-kod ligger utanför webbserverns rot. Detta säkerställer att din Python-kod inte av misstag visas som ren text (eller av misstag exekveras).
Var försiktig med alla användaruppladdade filer.
Django stryper inte förfrågningar om autentisering av användare. För att skydda mot brute-force-attacker mot autentiseringssystemet kan du överväga att distribuera ett Django-plugin eller en webbservermodul för att strypa dessa begäranden.
Håll din SECRET_KEY, och SECRET_KEY_FALLBACKS om den används, hemlig.
Det är en god idé att begränsa tillgängligheten till ditt cachningssystem och din databas med hjälp av en brandvägg.
Ta en titt på Open Web Application Security Project (OWASP) Top 10-lista som identifierar några vanliga sårbarheter i webbapplikationer. Django har verktyg för att hantera vissa av dessa problem, men andra problem måste beaktas i utformningen av ditt projekt.
Mozilla diskuterar olika ämnen som rör webbsäkerhet. Deras sidor innehåller också säkerhetsprinciper som gäller för alla system.