Django 1.4.14 release notes¶
20 augusti 2014
Django 1.4.14 åtgärdar flera säkerhetsproblem i 1.4.13.
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 med adminändringsformulär. Till exempel, genom att begära en URL som /admin/auth/user/?pop=1&t=password och visa sidans HTML kunde man visa lösenordshash 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.
