March 1, 2016
\nDjango 1.9.3 fixes two security issues and several bugs in 1.9.2.
\nDjango relies on user input in some cases (e.g.\ndjango.contrib.auth.views.login() and i18n)\nto redirect the user to an “on success” URL. The security check for these\nredirects (namely django.utils.http.is_safe_url()) considered some URLs\nwith basic authentication credentials “safe” when they shouldn’t be.
For example, a URL like http://mysite.example.com\\@attacker.com would be\nconsidered safe if the request’s host is http://mysite.example.com, but\nredirecting to this URL sends the user to attacker.com.
Also, if a developer relies on is_safe_url() to provide safe redirect\ntargets and puts such a URL into a link, they could suffer from an XSS attack.
In each major version of Django since 1.6, the default number of iterations for\nthe PBKDF2PasswordHasher and its subclasses has increased. This improves\nthe security of the password as the speed of hardware increases, however, it\nalso creates a timing difference between a login request for a user with a\npassword encoded in an older number of iterations and login request for a\nnonexistent user (which runs the default hasher’s default number of iterations\nsince Django 1.6).
This only affects users who haven’t logged in since the iterations were\nincreased. The first time a user logs in after an iterations increase, their\npassword is updated with the new iterations and there is no longer a timing\ndifference.
\nThe new BasePasswordHasher.harden_runtime() method allows hashers to bridge\nthe runtime gap between the work factor (e.g. iterations) supplied in existing\nencoded passwords and the default work factor of the hasher. This method\nis implemented for PBKDF2PasswordHasher and BCryptPasswordHasher.\nThe number of rounds for the latter hasher hasn’t changed since Django 1.4, but\nsome projects may subclass it and increase the work factor as needed.
A warning will be emitted for any third-party password hashers that don’t\nimplement a harden_runtime() method.
If you have different password hashes in your database (such as SHA1 hashes\nfrom users who haven’t logged in since the default hasher switched to PBKDF2\nin Django 1.4), the timing difference on a login request for these users may be\neven greater and this fix doesn’t remedy that difference (or any difference\nwhen changing hashers). You may be able to upgrade those hashes to prevent a timing attack for that case.
\nSkipped URL checks (new in 1.9) if the ROOT_URLCONF setting isn’t defined\n(#26155).
Fixed a crash on PostgreSQL that prevented using TIME_ZONE=None and\nUSE_TZ=False (#26177).
Added system checks for query name clashes of hidden relationships\n(#26162).
Fixed a regression for cases where\nForeignObject.get_extra_descriptor_filter() returned a Q object\n(#26153).
Fixed regression with an __in=qs lookup for a ForeignKey with\nto_field set (#26196).
Made forms.FileField and utils.translation.lazy_number() picklable\n(#26212).
Fixed RangeField and\nArrayField serialization with\nNone values (#26215).
Fixed a crash when filtering by a Decimal in RawQuery\n(#26219).
Reallowed dashes in top-level domain names of URLs checked by\nURLValidator to fix a regression in Django 1.8 (#26204).
Fixed some crashing deprecation shims in SimpleTemplateResponse that\nregressed in Django 1.9 (#26253).
Fixed BoundField to reallow slices of subwidgets (#26267).
Changed the admin’s “permission denied” message in the login template to use\nget_username instead of username to support custom user models\n(#26231).
Fixed a crash when passing a nonexistent template name to the cached template\nloader’s load_template() method (#26280).
Prevented ContentTypeManager instances from sharing their cache\n(#26286).
Reverted a change in Django 1.9.2 (#25858) that prevented relative\nlazy relationships defined on abstract models to be resolved according to\ntheir concrete model’s app_label (#26186).