# Django 6.0.7 documentation

# Django 1.8.10 versionsinformation

1 mars 2016

Django 1.8.10 åtgärdar två säkerhetsproblem och flera buggar i 1.8.9.

## CVE-2016-2512: Skadlig omdirigering och möjlig XSS-attack via användartillhandahållna omdirigeringsadresser som innehåller grundläggande autentisering

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äkerhetskontrollen för dessa omdirigeringar (nämligen `django.utils.http.is_safe_url()`) ansåg att vissa webbadresser med grundläggande autentiseringsuppgifter var ”säkra” när de inte borde vara det.

Till exempel skulle en URL som `http://mysite.example.com\@attacker.com` betraktas som säker om värdadressen för begäran är `http://mysite.example.com`, men om användaren omdirigeras till denna URL skickas användaren till `attacker.com`.

Om en utvecklare förlitar sig på `is_safe_url()` för att tillhandahålla säkra omdirigeringsmål och lägger in en sådan URL i en länk, kan de också drabbas av en XSS-attack.

## CVE-2016-2513: Uppräkning av användare genom tidsskillnad vid uppgradering av lösenordshashers arbetsfaktor

I varje större version av Django sedan 1.6 har standardantalet iterationer för `PBKDF2PasswordHasher` och dess underklasser ökat. Detta förbättrar lösenordets säkerhet när hårdvarans hastighet ökar, men det skapar också en tidsskillnad mellan en inloggningsbegäran för en användare med ett lösenord kodat i ett äldre antal iterationer och inloggningsbegäran för en icke-existerande användare (som kör standardhasherens standardantal iterationer sedan Django 1.6).

Detta påverkar endast användare som inte har loggat in sedan iterationerna höjdes. Första gången en användare loggar in efter en ökning av iterationerna uppdateras lösenordet med de nya iterationerna och det finns inte längre någon tidsskillnad.

Den nya metoden `BasePasswordHasher.harden_runtime()` gör det möjligt för hashare att överbrygga körtidsgapet mellan arbetsfaktorn (t.ex. iterationer) som tillhandahålls i befintliga kodade lösenord och standardarbetsfaktorn för hasharen. Den här metoden är implementerad för `PBKDF2PasswordHasher` och `BCryptPasswordHasher`. Antalet rundor för den senare hasharen har inte ändrats sedan Django 1.4, men vissa projekt kan underklassa den och öka arbetsfaktorn efter behov.

En varning kommer att skickas ut för alla tredjeparts lösenordshashers som inte implementerar en `harden_runtime()` metod.

Om du har olika lösenordshashar i din databas (t.ex. SHA1-hashar från användare som inte har loggat in sedan standardhashern bytte till PBKDF2 i Django 1.4) kan tidsskillnaden på en inloggningsbegäran för dessa användare vara ännu större och den här fixen avhjälper inte den skillnaden (eller någon skillnad när du byter hasher). Du kanske kan uppgradera dessa hasher för att förhindra en tidsattack i det fallet.

## Buggrättningar

- Fixade en krasch på PostgreSQL som förhindrade användning av `TIME_ZONE=None` och `USE_TZ=False` (#26177`).

- Lagt till systemkontroller för kollisioner mellan frågenamn i dolda relationer (#26162).

- Gjorde `forms.FileField` och `utils.translation.lazy_number()` picklable (#26212).

- Fixat `RangeField` och `ArrayField` serialisering med `None` värden (#26215).

- Tillåter bindestreck i toppdomännamn för URL:er som kontrolleras av `URLValidator` för att åtgärda en regression i Django 1.8 (#26204).

- Fixade `BoundField` så att det inte längre är tillåtet att dela upp subwidgets (#26267).

- Förhindrade `ContentTypeManager`-instanser från att dela sin cache (#26286).