# Django 6.0.5 documentation

# Django 1.6.10 versionsinformation

13 januari 2015

Django 1.6.10 åtgärdar flera säkerhetsproblem i 1.6.9.

## WSGI header spoofing via sammanblandning av understreck/streck

När HTTP-rubriker placeras i WSGI-miljön normaliseras de genom att konverteras till versaler, alla bindestreck konverteras till understreck och `HTTP_` läggs till. Till exempel skulle en header `X-Auth-User` bli `HTTP_X_AUTH_USER` i WSGI-miljön (och därmed också i Djangos `request.META`-ordbok).

Tyvärr innebär detta att WSGI-miljön inte kan skilja mellan headers som innehåller bindestreck och headers som innehåller understreck: `X-Auth-User` och `X-Auth_User` blir båda `HTTP_X_AUTH_USER`. Detta innebär att om ett huvud används på ett säkerhetskänsligt sätt (t.ex. vid överföring av autentiseringsinformation från en proxy i frontend), även om proxyn noggrant tar bort alla inkommande värden för `X-Auth-User`, kan en angripare kunna tillhandahålla ett `X-Auth_User`-huvud (med understreck) och kringgå detta skydd.

För att förhindra sådana attacker tar både Nginx och Apache 2.4+ som standard bort alla headers som innehåller understreck från inkommande förfrågningar. Djangos inbyggda utvecklingsserver gör nu detsamma. Djangos utvecklingsserver rekommenderas inte för produktionsanvändning, men genom att matcha beteendet hos vanliga produktionsservrar minskar ytan för beteendeförändringar under distributionen.

## Mildrad möjlig XSS-attack via användartillhandahållna omdirigeringsadresser

Django förlitar sig på användarinmatning i vissa fall (t.ex. `django.contrib.auth.views.login()` och i18n) för att omdirigera användaren till en ”on success” URL. Säkerhetskontrollerna för dessa omdirigeringar (nämligen `django.utils.http.is_safe_url()`) tog inte bort ledande blanksteg på den testade webbadressen och ansåg därför att webbadresser som `\njavascript:...` var säkra. Om en utvecklare förlitade sig på `is_safe_url()` för att tillhandahålla säkra omdirigeringsmål och lade in en sådan URL i en länk, kunde de drabbas av en XSS-attack. Denna bugg påverkar inte Django för närvarande, eftersom vi bara lägger in denna URL i svarshuvudet `Location` och webbläsare verkar ignorera JavaScript där.

## Denial-of-service-attack mot `django.views.static.serve`

I äldre versioner av Django läste vyn `django.views.static.serve()` filerna som den serverade en rad i taget. Därför skulle en stor fil utan nya rader resultera i minnesanvändning som är lika stor som filens storlek. En angripare kan utnyttja detta och starta en överbelastningsattack genom att samtidigt begära många stora filer. I den här vyn läses filen nu i bitar för att förhindra stor minnesanvändning.

Observera dock att den här vyn alltid har haft en varning om att den inte är härdad för produktionsanvändning och endast bör användas som ett utvecklingshjälpmedel. Nu kan det vara en bra tid att granska ditt projekt och servera dina filer i produktion med hjälp av en riktig front-end webbserver om du inte redan gör det.

## Denial-of-service för databas med `ModelMultipleChoiceField`

I ett formulär som använder `ModelMultipleChoiceField` och `show_hidden_initial=True` (inte ett dokumenterat API) var det möjligt för en användare att orsaka ett orimligt antal SQL-frågor genom att skicka in duplicerade värden för fältets data. Valideringslogiken i `ModelMultipleChoiceField` avdubblerar nu inskickade värden för att åtgärda detta problem.