# Django 6.0.7 documentation

# Django 1.4.21 versionsinformation

8 juli 2015

Django 1.4.21 åtgärdar flera säkerhetsproblem i 1.4.20.

## 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` och deras användning i motsvarande formulärfält `GenericIPAddresseField`, `IPAddressField`, `SlugField` och `URLField` påverkas också.

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.