Django 1.6.6 release notes¶
20 augusti 2014
Django 1.6.6 åtgärdar flera säkerhetsproblem och buggar i 1.6.5.
reverse()
kan generera webbadresser som pekar till andra värdar¶
I vissa situationer kan URL-reversering generera schemarelativa URL:er (URL:er som börjar med två snedstreck), som oväntat kan omdirigera en användare till en annan värd. En angripare kan utnyttja detta, t.ex. genom att omdirigera användare till en nätfiskewebbplats som är utformad för att be om användarens lösenord.
För att åtgärda detta säkerställer URL-reversering nu att ingen URL börjar med två snedstreck (//), och ersätter det andra snedstrecket med dess URL-kodade motsvarighet (%2F). Detta tillvägagångssätt säkerställer att semantiken förblir densamma, samtidigt som URL:en blir relativ till domänen och inte till schemat.
Förnekande av tjänst vid filuppladdning¶
Före den här utgåvan kan Djangos filuppladdningshantering i sin standardkonfiguration försämras till att producera ett stort antal os.stat()
systemanrop när ett duplicerat filnamn laddas upp. Eftersom stat()
kan anropa IO kan detta ge en enorm databeroende nedgång som långsamt förvärras över tiden. Nettoresultatet är att en användare som har möjlighet att ladda upp filer under tillräckligt lång tid kan orsaka dålig prestanda i uppladdningshanteraren och till slut göra den mycket långsam bara genom att ladda upp 0-byte-filer. Vid det här laget räcker det med en långsam nätverksanslutning och ett fåtal HTTP-förfrågningar för att göra en webbplats otillgänglig.
Vi har åtgärdat problemet genom att ändra algoritmen för att generera filnamn om en fil med det uppladdade namnet redan finns. Storage.get_available_name()
lägger nu till ett understreck plus en slumpmässig alfanumerisk sträng med 7 tecken (t.ex. "_x3a1gho"
), i stället för att iterera genom ett understreck följt av ett nummer (t.ex. "_1"
, "_2"
, etc.).
RemoteUserMiddleware
kapning av session¶
När man använder RemoteUserMiddleware
och RemoteUserBackend
, kan en ändring av REMOTE_USER
-huvudet mellan förfrågningar utan en mellanliggande utloggning resultera i att den tidigare användarens session tas över av den efterföljande användaren. Mellanvaran loggar nu ut användaren vid ett misslyckat inloggningsförsök.
Dataläckage via manipulering av frågesträngar i contrib.admin
¶
I äldre versioner av Django var det möjligt att avslöja data för valfritt fält genom att ändra parametrarna ”popup” och ”to_field” i frågesträngen på en sida för adminändringsformulär. Till exempel, genom att begära en URL som /admin/auth/user/?_popup=1&t=password
och visa sidans HTML kunde man visa lösenordshashen för varje användare. Även om administratören kräver att användarna har behörighet att visa ändringsformulärsidorna i första hand, kan detta läcka data om du förlitar dig på att användarna bara har tillgång till att visa vissa fält i en modell.
För att lösa problemet kommer nu ett undantag att uppstå om ett to_field
-värde som inte är ett relaterat fält till en modell som har registrerats hos administratören anges.
Buggrättningar¶
Validering av e-post och URL har korrigerats så att ett efterföljande bindestreck (#22579) inte accepteras.
Förhindrade index på PostgreSQL virtuella fält (:biljett:`22514`).
Förhindrade kantfall där värden för FK-fält kunde initieras med ett felaktigt värde när ett formulär för en inline-modell skapas för en relation som definieras för att peka på ett annat fält än PK (#13794).
Återställde
pre_delete
signaler förGenericRelation
kaskad radering (#22998).Fixad transaktionshantering när en icke-standarddatabas anges i
createcachetable
ochflush
(#23089).Felet ”ORA-01843: not a valid month” åtgärdades när Unicode användes med äldre versioner av Oracle Server (#20292).
Återställd buggfix för att skicka Unicode e-post med Python 2.6.5 och lägre (#19107).
Förhindrade
UnicodeDecodeError
irunserver
med icke-UTF-8 och icke-engelsk locale (#23265).Fixade JavaScript-fel vid redigering av multi-geometriobjekt i OpenLayers-widgeten (#23137, #23293).
Förhindrade en krasch i Python 3 med frågesträngar som innehåller okodade icke-ASCII-tecken (#22996).