Django 1.8.10 release notes

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).