Detta dokument är en översikt över Djangos säkerhetsfunktioner. Det innehåller råd om hur du säkrar en Djangodriven webbplats.
\n\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.
\nVid en skriptövergripande attack injiceras skadlig kod i form av ett skript på klientsidan i en annan användares webbläsare, där den körs.
\nDetta görs vanligen genom att:
\nlagra det skadliga skriptet i databasen, där det hämtas och visas för andra användare i deras webbläsare, eller
få användare att klicka på en länk som gör att angriparens JavaScript körs i användarens webbläsare.
Cross-site scripting-angrepp kan komma från vilken otillförlitlig datakälla som helst, inklusive kakor eller webbtjänster, om data inte rensas tillräckligt innan de publiceras på en sida.
\nDjango-mallar skyddar mot majoriteten av skriptövergripande attacker genom att automatiskt undanta tecken som utgör en risk (det vill säga HTML-tecken som webbläsaren skulle kunna tolka med skadlig effekt visas i stället säkert).
\nSkyddets omfattning och begränsningar bör dock förstås.
\nTvetydighet mellan utvecklarens avsikt och hur webbläsaren tolkar HTML kan utsätta klienten för oavsiktlig exekvering av kod. Anta att en utvecklare skapar:
\n<style class={{ var }}>...</style>\ndär var förväntas innehålla något i stil med 'class1'. Om var i stället sätts till 'class1 onmouseover=javascript:func()' kan detta leda till otillåten körning av JavaScript på grund av skillnader i hur webbläsare tolkar denna bristfälliga HTML.
En uttrycklig mallutformning där citattecknen inte lämnas åt variabeln att tillhandahålla:
\n<style class="{{ var }}">...</style>\nskulle undanröja denna möjlighet.
\nDet är också viktigt att vara särskilt försiktig när attributet is_safe används med egna malltaggar, mallfiltret safe, mark_safe och när automatisk undantagning är avstängd.
Djangos inbyggda undantagning är avsedd att skydda HTML-utdata. Om mallsystemet används för att skapa något annat än HTML kan de tecken och strängar som kräver undantagning vara helt annorlunda.
\nVar dessutom mycket försiktig när HTML lagras i databasen, särskilt när HTML:en hämtas och visas. Om HTML:en inte garanterat kommer från en betrodd källa – användarindata är inte en betrodd källa – bör lagrad HTML kontrolleras och saneras, helst både vid indata och utdata.
\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 rubriken Host som tillhandahålls av klienten för att konstruera URL:er i vissa fall. Dessa värden saneras för att förhindra skriptövergripande attacker, men ett förfalskat Host-värde kan användas för förfalskade begäranden mellan webbplatser, cacheförgiftningsattacker och förgiftning av länkar i e-postmeddelanden.
Eftersom även till synes säkra webbserverkonfigurationer är mottagliga för förfalskade Host-rubriker validerar Django Host-rubriker mot inställningen ALLOWED_HOSTS i metoden django.http.HttpRequest.get_host().
Denna validering tillämpas endast via get_host(); om din kod hämtar 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.
Cross-Origin Resource Sharing (CORS) styr vilka ursprung som får åtkomst till resurser från din webbplats via webbläsaren. Django har inte inbyggt stöd för CORS-rubriker.
\n\nI 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 webbplatsen tar emot filuppladdningar rekommenderas starkt att begränsa dessa till en rimlig storlek i webbserverkonfigurationen för att förebygga överbelastningsangrepp (DoS). I Apache kan detta enkelt anges med direktivet LimitRequestBody. Du bör inte enbart förlita dig på DATA_UPLOAD_MAX_MEMORY_SIZE eller FILE_UPLOAD_MAX_MEMORY_SIZE.
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.
Formulärinskick som innehåller filer begränsas inte av DATA_UPLOAD_MAX_MEMORY_SIZE. Under ASGI kan hela begäran buffras till disk innan någon kontroll av filstorlek utförs. Det rekommenderas starkt att begränsa maximal storlek på begärandetexten i webbserverkonfigurationen för att förebygga överbelastningsangrepp (DoS).
Content Security Policy (CSP) är en säkerhetsmekanism i webbläsaren som hjälper till att skydda webbapplikationer mot angrepp som cross-site scripting (XSS) och andra innehållsinjektionsangrepp.
\nCSP gör det möjligt för webbapplikationer att definiera vilka innehållskällor som är betrodda och instruerar webbläsaren att läsa in, köra eller återge resurser endast från dessa källor. Detta skapar i praktiken en tillåtelselista över innehållsursprung och minskar risken för körning av skadlig kod.
\nViktiga fördelar med att aktivera CSP är bland annat:
\nMildra XSS-angrepp genom att blockera inbäddade skript och begränsa inläsning av externa skript.
Kontroll över vilka externa resurser (till exempel bilder, teckensnitt och formatmallar) som kan läsas in.
Förhindra oönskad inramning av webbplatsen för att skydda mot clickjacking.
Rapportera överträdelser till en angiven slutpunkt för att möjliggöra övervakning och felsökning.
Konfigurationsinstruktioner finns i dokumentationen Använda CSP. Se CSP-översikten för mer information om direktiv och inställningar.
\nÄven om CSP är en kraftfull säkerhetsmekanism är det viktigt att förstå dess begränsningar och konsekvenser, särskilt när den används i Django:
\nRisker med policyundantag: Undvik att undanta specifika sökvägar eller svar från CSP-skydd. På grund av webbläsarens princip om samma ursprung kan en sårbarhet på en oskyddad sida (till exempel en som tillåter godtycklig skriptinjektion) användas för att angripa skyddade sidor. Att undanta vilken väg som helst kan avsevärt försvaga webbplatsens samlade CSP-skydd.
Prestandaomkostnad: Även om den vanligen är försumbar medför CSP viss bearbetningskostnad. Nonce-generering kräver säker slumpmässighet för varje tillämplig begäran. Mät prestandapåverkan för applikationer med hög trafik eller miljöer med begränsade resurser.
Webbläsarstöd: Även om CSP nivå 1 och 2 har brett stöd kan nyare direktiv (CSP nivå 3+) eller komplexa policybeteenden skilja sig mellan webbläsare. Testa policyn i de miljöer som ska stödjas.
Trots dessa begränsningar är CSP fortfarande ett viktigt och rekommenderat säkerhetslager för webbapplikationer. Att förstå begränsningarna hjälper dig att utforma en effektivare och tillförlitligare driftsättning.
\nÄ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.