Django 1.4.18 release notes¶
13 januari 2015
Django 1.4.18 åtgärdar flera säkerhetsproblem i 1.4.17 samt en regression på Python 2.5 i 1.4.17-utgåvan.
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.
Buggrättningar¶
För att upprätthålla kompatibiliteten med Python 2.5 har Djangos version av Six,
django.utils.six, nedgraderats till 1.8.0, vilket är den sista versionen som stöder Python 2.5.
