Django 1.4.11 release notes¶
21 april 2014
Django 1.4.11 åtgärdar tre säkerhetsproblem i 1.4.10. Dessutom har Djangos vendored version av six, django.utils.six, uppgraderats till den senaste versionen (1.6.1).
Oväntad exekvering av kod med reverse()¶
Djangos URL-hantering baseras på en mappning av regex-mönster (som representerar URL:erna) till anropsbara vyer, och Djangos egen bearbetning består av att matcha en begärd URL mot dessa mönster för att avgöra vilken vy som är lämplig att anropa.
Django tillhandahåller också en bekvämlighetsfunktion - reverse() - som utför denna process i motsatt riktning. Funktionen reverse() tar information om en vy och returnerar en URL som skulle anropa den vyn. Användningen av reverse() uppmuntras för applikationsutvecklare, eftersom utdata från reverse() alltid baseras på de aktuella URL-mönstren, vilket innebär att utvecklare inte behöver ändra annan kod när de gör ändringar i webbadresser.
En argumentsignatur för reverse() är att skicka en prickad Python-sökväg till önskad vy. I den här situationen kommer Django att importera den modul som anges av den prickade sökvägen som en del av genereringen av den resulterande webbadressen. Om en sådan modul har bieffekter vid import, kommer dessa bieffekter att uppstå.
Det är därför möjligt för en angripare att orsaka oväntad exekvering av kod under följande förutsättningar:
Det finns en eller flera vyer som konstruerar en URL baserat på användarinmatning (vanligtvis en ”next”-parameter i en frågestring som anger vart man ska omdirigeras när en åtgärd har slutförts).
En eller flera moduler är kända av en angripare för att finnas på serverns Python-importväg, som utför kodkörning med sidoeffekter vid import.
För att åtgärda detta kommer reverse() nu endast att acceptera och importera prickade sökvägar baserade på de moduler som innehåller vyer och som listas i projektets URL pattern configuration, för att säkerställa att endast moduler som utvecklaren avsett att importeras på detta sätt kan eller kommer att importeras.
Cachelagring av anonyma sidor kan avslöja CSRF-token¶
Django innehåller både ett caching-ramverk och ett system för att förhindra CSRF-attacker (cross-site request forgery). CSRF-skyddssystemet är baserat på en slumpmässig nonce som skickas till klienten i en cookie som måste skickas av klienten vid framtida förfrågningar och, i formulär, ett dolt värde som måste skickas tillbaka med formuläret.
Cachelagringsramverket innehåller ett alternativ för att cacha svar till anonyma (dvs. oautentiserade) klienter.
När den första anonyma begäran till en viss sida görs av en klient som inte har en CSRF-cookie, kommer cache-ramverket även att cachelagra CSRF-cookien och servera samma nonce till andra anonyma klienter som inte har en CSRF-cookie. Detta kan göra det möjligt för en angripare att få ett giltigt CSRF-cookievärde och utföra attacker som kringgår kontrollen av cookien.
För att åtgärda detta kommer cachningsramverket inte längre att cacha sådana svar. Heuristiken för detta kommer att vara:
Om den inkommande begäran inte innehöll några cookies, och
Om svaret skickade en eller flera cookies, och
Om rubriken
Vary: Cookieanges i svaret, kommer svaret inte att cachas.
MySQL typberäkning¶
MySQL-databasen är känd för att ”typecast” på vissa frågor; till exempel, när du frågar en tabell som innehåller strängvärden, men använder en fråga som filtrerar baserat på ett heltalsvärde, kommer MySQL först tyst att tvinga strängarna till heltal och returnera ett resultat baserat på det.
Om en fråga utförs utan att värdena först konverteras till rätt typ kan det ge oväntade resultat, liknande dem som skulle uppstå om själva frågan hade manipulerats.
Djangos modellfältklasser är medvetna om sina egna typer och de flesta sådana klasser utför explicit konvertering av frågeargument till rätt typ på databasnivå innan frågan ställs. Tre modellfältklasser konverterade dock inte sina argument korrekt:
IPAddressField
Dessa tre fält har uppdaterats för att konvertera sina argument till rätt typ före förfrågan.
Dessutom varnas nu utvecklare av anpassade modellfält via dokumentation för att säkerställa att deras anpassade fältklasser kommer att utföra lämpliga typkonverteringar, och användare av frågemetoderna raw() och extra() - som gör det möjligt för utvecklaren att tillhandahålla rå SQL eller SQL-fragment - rekommenderas att säkerställa att de utför lämpliga manuella typkonverteringar innan de kör frågor.
