Django 1.6.11 release notes

18 mars 2015

Django 1.6.11 åtgärdar två säkerhetsproblem i 1.6.10.

Möjligheten till överbelastningsskydd med strip_tags()

Förra året ändrades strip_tags() till att arbeta iterativt. Problemet är att storleken på indata som bearbetas kan öka för varje iteration vilket resulterar i en oändlig loop i strip_tags(). Detta problem påverkar endast versioner av Python som inte har fått a bugfix in HTMLParser; nämligen Python < 2.7.7 och 3.3.5. Vissa operativsystemleverantörer har också bakåtporterat rättelsen för Python-buggen till sina paket med tidigare versioner.

För att åtgärda detta problem kommer strip_tags() nu att returnera den ursprungliga inmatningen om den upptäcker att längden på strängen den bearbetar ökar. Kom ihåg att det absolut INTE finns någon garanti för att resultatet av strip_tags() är HTML-säkert. Så markera ALDRIG resultatet av ett strip_tags()-anrop som säkert utan att först escapa det, t.ex. med escape().

Mildrad möjlig XSS-attack via användartillhandahållna omdirigeringsadresser

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äkerhetskontrollerna för dessa omdirigeringar (nämligen django.utils.http.is_safe_url()) accepterade webbadresser med ledande kontrolltecken och ansåg därför att webbadresser som \x08javascript:... var säkra. Detta problem påverkar inte Django för närvarande, eftersom vi bara lägger in denna URL i svarshuvudet Location och webbläsare verkar ignorera JavaScript där. Webbläsare som vi testade behandlar också webbadresser med kontrolltecken som %08//example.com som relativa sökvägar, så omdirigering till ett osäkert mål är inte heller ett problem.

Men 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 drabbas av en XSS-attack eftersom vissa webbläsare som Google Chrome ignorerar kontrolltecken i början av en URL i ankaret href.