- Language: en
Django 1.6.6 release notes¶
August 20, 2014
Django 1.6.6 fixes several security issues and bugs in 1.6.5.
reverse()
could generate URLs pointing to other hosts¶
In certain situations, URL reversing could generate scheme-relative URLs (URLs starting with two slashes), which could unexpectedly redirect a user to a different host. An attacker could exploit this, for example, by redirecting users to a phishing site designed to ask for user’s passwords.
To remedy this, URL reversing now ensures that no URL starts with two slashes (//), replacing the second slash with its URL encoded counterpart (%2F). This approach ensures that semantics stay the same, while making the URL relative to the domain and not to the scheme.
File upload denial-of-service¶
Before this release, Django’s file upload handing in its default configuration
may degrade to producing a huge number of os.stat()
system calls when a
duplicate filename is uploaded. Since stat()
may invoke IO, this may produce
a huge data-dependent slowdown that slowly worsens over time. The net result is
that given enough time, a user with the ability to upload files can cause poor
performance in the upload handler, eventually causing it to become very slow
simply by uploading 0-byte files. At this point, even a slow network connection
and few HTTP requests would be all that is necessary to make a site unavailable.
We’ve remedied the issue by changing the algorithm for generating file names
if a file with the uploaded name already exists.
Storage.get_available_name()
now appends an
underscore plus a random 7 character alphanumeric string (e.g. "_x3a1gho"
),
rather than iterating through an underscore followed by a number (e.g. "_1"
,
"_2"
, etc.).
RemoteUserMiddleware
session hijacking¶
When using the RemoteUserMiddleware
and the RemoteUserBackend
, a change to the REMOTE_USER
header between
requests without an intervening logout could result in the prior user’s session
being co-opted by the subsequent user. The middleware now logs the user out on
a failed login attempt.
Data leakage via query string manipulation in contrib.admin
¶
In older versions of Django it was possible to reveal any field’s data by
modifying the “popup” and “to_field” parameters of the query string on an admin
change form page. For example, requesting a URL like
/admin/auth/user/?_popup=1&t=password
and viewing the page’s HTML allowed
viewing the password hash of each user. While the admin requires users to have
permissions to view the change form pages in the first place, this could leak
data if you rely on users having access to view only certain fields on a model.
To address the issue, an exception will now be raised if a to_field
value
that isn’t a related field to a model that has been registered with the admin
is specified.
Bugfixes¶
- Corrected email and URL validation to reject a trailing dash (#22579).
- Prevented indexes on PostgreSQL virtual fields (#22514).
- Prevented edge case where values of FK fields could be initialized with a wrong value when an inline model formset is created for a relationship defined to point to a field other than the PK (#13794).
- Restored
pre_delete
signals forGenericRelation
cascade deletion (#22998). - Fixed transaction handling when specifying non-default database in
createcachetable
andflush
(#23089). - Fixed the “ORA-01843: not a valid month” errors when using Unicode with older versions of Oracle server (#20292).
- Restored bug fix for sending Unicode email with Python 2.6.5 and below (#19107).
- Prevented
UnicodeDecodeError
inrunserver
with non-UTF-8 and non-English locale (#23265). - Fixed JavaScript errors while editing multi-geometry objects in the OpenLayers widget (#23137, #23293).
- Prevented a crash on Python 3 with query strings containing unencoded non-ASCII characters (#22996).