Django 1.7.9 release notes¶
8 juli 2015
Django 1.7.9 åtgärdar flera säkerhetsproblem och buggar i 1.7.8.
Möjligheten att neka tjänst genom att fylla sessionslagret¶
I tidigare versioner av Django skapade sessionsbackends en ny tom post i sessionslagret varje gång request.session öppnades och det fanns en sessionsnyckel som tillhandahölls i begäran cookies som inte redan hade en sessionspost. Detta kan göra det möjligt för en angripare att enkelt skapa många nya sessionsposter helt enkelt genom att skicka upprepade förfrågningar med okända sessionsnycklar, vilket potentiellt kan fylla upp sessionslagret eller orsaka att andra användares sessionsposter kastas ut.
De inbyggda sessionsbackends skapar nu en sessionspost endast om sessionen faktiskt ändras; tomma sessionsposter skapas inte. Därför är denna potentiella DoS nu endast möjlig om webbplatsen väljer att exponera en sessionsmodifierande vy för anonyma användare.
Eftersom varje inbyggd sessionsbackend åtgärdades separat (i stället för en åtgärd i kärnramverket för sessioner), bör underhållare av sessionsbackends från tredje part kontrollera om samma sårbarhet finns i deras backend och åtgärda den om så är fallet.
Möjlighet att injicera rubriker eftersom validerare accepterar nya rader i indata¶
Vissa av Djangos inbyggda validerare (EmailValidator, mest allvarligt) förbjöd inte tecken med nya rader (på grund av användningen av $ istället för \Z i de reguljära uttrycken). Om du använder värden med nya rader i HTTP-svar eller e-postheaders kan du drabbas av header injection-attacker. Django i sig är inte sårbart eftersom HttpResponse och verktygen för att skicka e-post i django.core.mail förbjuder nya rader i HTTP- respektive SMTP-rubriker. Validerarna har åtgärdats i Django, men om du skapar HTTP-svar eller e-postmeddelanden på andra sätt är det en bra idé att se till att dessa metoder också förbjuder nya rader. Du kanske också vill validera att befintliga data i din applikation inte innehåller oväntade nya rader.
validate_ipv4_address(), validate_slug(), och URLValidator påverkas också, men från och med Django 1.6 formfälten GenericIPAddresseField, IPAddressField, SlugField och URLField som använder dessa validerare alla inmatningen, så möjligheten att nya rader kommer in i dina data finns bara om du använder dessa validerare utanför formfälten.
Den odokumenterade, internt oanvända funktionen validate_integer() är nu striktare eftersom den validerar med hjälp av ett reguljärt uttryck istället för att bara kasta värdet med int() och kontrollera om ett undantag uppstod.
