Django 1.4.3 release notes

10 december 2012

Django 1.4.3 åtgärdar två säkerhetsproblem som fanns i tidigare Django-versioner i 1.4-serien.

Observera att denna säkerhetsrelease skiljer sig något från tidigare. Båda problemen som tas upp här har hanterats i tidigare säkerhetsuppdateringar av Django. I det ena fallet har vi fått löpande rapporter om problem, och i det andra fallet har vi valt att vidta ytterligare åtgärder för att strama upp Djangos kod som svar på oberoende upptäckter av potentiella problem från flera källor.

Förgiftning av värdhuvud

Flera tidigare säkerhetsreleaser för Django fokuserade på frågan om förgiftning av HTTP Host-headern, vilket fick Django att generera webbadresser som pekade på godtyckliga, potentiellt skadliga domäner.

Som svar på ytterligare input och rapporter om fortsatta problem efter den tidigare utgåvan, tar vi ytterligare steg för att skärpa valideringen av värdhuvudet. I stället för att försöka tillgodose alla funktioner som HTTP stöder här, försöker Djangos validering av värdhuvudet att stödja en mindre, men mycket vanligare, delmängd:

• Värdnamn måste bestå av tecknen [A-Za-z0-9] plus bindestreck (’-’) eller punkt (’.’).

• IP-adresser - både IPv4 och IPv6 - är tillåtna.

• Port, om den anges, är numerisk.

Alla avvikelser från detta kommer nu att avvisas, vilket ger upphov till undantaget django.core.exceptions.SuspiciousOperation.

Förgiftning av omdirigering

Vi följer också upp en tidigare fråga: i juli i år gjorde vi ändringar i Djangos HTTP-omdirigeringsklasser och utförde ytterligare validering av schemat för webbadressen som ska omdirigeras till (eftersom det är ett vanligt mönster att acceptera ett användartillhandahållet omdirigeringsmål, både inom Djangos egna applikationer och många tredjepartsapplikationer).

Sedan dess har två oberoende granskningar av koden visat på ytterligare potentiella problem. Så på samma sätt som med Host-header-problemet vidtar vi åtgärder för att tillhandahålla strängare validering som svar på rapporterade problem (främst med tredjepartsapplikationer, men i viss utsträckning också inom Django själv). Detta kommer i två delar:

1. A new utility function, django.utils.http.is_safe_url, is added; this function takes a URL and a hostname, and checks that the URL is either relative, or if absolute matches the supplied hostname. This function is intended for use whenever user-supplied redirect targets are accepted, to ensure that such redirects cannot lead to arbitrary third-party sites.

2. All of Django’s own built-in views – primarily in the authentication system – which allow user-supplied redirect targets now use is_safe_url to validate the supplied URL.