Notas de lançamento do Django 1.9.3¶
March 1, 2016
Django 1.9.3 fixes two security issues and several bugs in 1.9.2.
CVE-2016-2512: Malicious redirect and possible XSS attack via user-supplied redirect URLs containing basic auth¶
Django relies on user input in some cases (e.g.
django.contrib.auth.views.login()
and i18n)
to redirect the user to an “on success” URL. The security check for these
redirects (namely django.utils.http.is_safe_url()
) considered some URLs
with basic authentication credentials “safe” when they shouldn’t be.
For example, a URL like http://mysite.example.com\@attacker.com
would be
considered safe if the request’s host is http://mysite.example.com
, but
redirecting to this URL sends the user to attacker.com
.
Also, if a developer relies on is_safe_url()
to provide safe redirect
targets and puts such a URL into a link, they could suffer from an XSS attack.
CVE-2016-2513: User enumeration through timing difference on password hasher work factor upgrade¶
In each major version of Django since 1.6, the default number of iterations for
the PBKDF2PasswordHasher
and its subclasses has increased. This improves
the security of the password as the speed of hardware increases, however, it
also creates a timing difference between a login request for a user with a
password encoded in an older number of iterations and login request for a
nonexistent user (which runs the default hasher’s default number of iterations
since Django 1.6).
This only affects users who haven’t logged in since the iterations were increased. The first time a user logs in after an iterations increase, their password is updated with the new iterations and there is no longer a timing difference.
The new BasePasswordHasher.harden_runtime()
method allows hashers to bridge
the runtime gap between the work factor (e.g. iterations) supplied in existing
encoded passwords and the default work factor of the hasher. This method
is implemented for PBKDF2PasswordHasher
and BCryptPasswordHasher
.
The number of rounds for the latter hasher hasn’t changed since Django 1.4, but
some 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
implement a harden_runtime()
method.
If you have different password hashes in your database (such as SHA1 hashes from users who haven’t logged in since the default hasher switched to PBKDF2 in Django 1.4), the timing difference on a login request for these users may be even greater and this fix doesn’t remedy that difference (or any difference when changing hashers). You may be able to upgrade those hashes to prevent a timing attack for that case.
Bugfixes¶
- Skipped URL checks (new in 1.9) if the
ROOT_URLCONF
setting isn’t defined (#26155). - Fixed a crash on PostgreSQL that prevented using
TIME_ZONE=None
andUSE_TZ=False
(#26177). - Added system checks for query name clashes of hidden relationships (#26162).
- Fixed a regression for cases where
ForeignObject.get_extra_descriptor_filter()
returned aQ
object (#26153). - Consertada a regressão quando de uma busca
__in=qs
para umaForeignKey
que utilizato_field
(#26196). - Made
forms.FileField
andutils.translation.lazy_number()
picklable (#26212). - Fixed
RangeField
andArrayField
serialization withNone
values (#26215). - Consertada a quebra quando filtrando por um
Decimal
em umaRawQuery
(#26219). - Reallowed dashes in top-level domain names of URLs checked by
URLValidator
to fix a regression in Django 1.8 (#26204). - Fixed some crashing deprecation shims in
SimpleTemplateResponse
that regressed in Django 1.9 (#26253). - Fixed
BoundField
to reallow slices of subwidgets (#26267). - Modificada a mensagem de “permissão negada” do admin no template de login para usar
get_username
ao invés deusername
para suportar modelos customizados de usuário (#26231). - Conserta a quebra quando fornecido um nome de template que não existe para a função
load_template()
do carregador de templates em cache (#26280). - Prevented
ContentTypeManager
instances from sharing their cache (#26286). - Revertida a mudança no Django 1.9.2 (#25858) que previniu que relativas relações preguiçosas definidas em modelos abstratos fossem resolvidas de acordo com o
app_labels
de seus modelos concretos (#26186).