Django

Latest version: v5.0.4

Safety actively analyzes 621673 Python packages for vulnerabilities to keep your Python projects secure.

Scan your dependencies

Page 34 of 52

1.9.8

Not secure
==========================

*July 18, 2016*

Django 1.9.8 fixes a security issue and several bugs in 1.9.7.

XSS in admin's add/change related popup
=======================================

Unsafe usage of JavaScript's ``Element.innerHTML`` could result in XSS in the
admin's add/change related popup. ``Element.textContent`` is now used to
prevent execution of the data.

The debug view also used ``innerHTML``. Although a security issue wasn't
identified there, out of an abundance of caution it's also updated to use
``textContent``.

Bugfixes
========

* Fixed missing ``varchar/text_pattern_ops`` index on ``CharField`` and
``TextField`` respectively when using ``AddField`` on PostgreSQL
(:ticket:`26889`).

* Fixed ``makemessages`` crash on Python 2 with non-ASCII file names
(:ticket:`26897`).


==========================

1.9.7

Not secure
==========================

*June 4, 2016*

Django 1.9.7 fixes several bugs in 1.9.6.

Bugfixes
========

* Removed the need for the ``request`` context processor on the admin login
page to fix a regression in 1.9 (:ticket:`26558`).

* Fixed translation of password validators' ``help_text`` in forms
(:ticket:`26544`).

* Fixed a regression causing the cached template loader to crash when using
lazy template names (:ticket:`26603`).

* Fixed ``on_commit`` callbacks execution order when callbacks make
transactions (:ticket:`26627`).

* Fixed ``HStoreField`` to raise a ``ValidationError`` instead of crashing on
non-dictionary JSON input (:ticket:`26672`).

* Fixed ``dbshell`` crash on PostgreSQL with an empty database name
(:ticket:`26698`).

* Fixed a regression in queries on a ``OneToOneField`` that has ``to_field``
and ``primary_key=True`` (:ticket:`26667`).


==========================

1.9.6

Not secure
==========================

*May 2, 2016*

Django 1.9.6 fixes several bugs in 1.9.5.

Bugfixes
========

* Added support for relative path redirects to the test client and to
``SimpleTestCase.assertRedirects()`` because Django 1.9 no longer converts
redirects to absolute URIs (:ticket:`26428`).

* Fixed ``TimeField`` microseconds round-tripping on MySQL and SQLite
(:ticket:`26498`).

* Prevented ``makemigrations`` from generating infinite migrations for a model
field that references a ``functools.partial`` (:ticket:`26475`).

* Fixed a regression where ``SessionBase.pop()`` returned ``None`` rather than
raising a ``KeyError`` for nonexistent values (:ticket:`26520`).

* Fixed a regression causing the cached template loader to crash when using
template names starting with a dash (:ticket:`26536`).

* Restored conversion of an empty string to null when saving values of
``GenericIPAddressField`` on SQLite and MySQL (:ticket:`26557`).

* Fixed a ``makemessages`` regression where temporary ``.py`` extensions were
leaked in source file paths (:ticket:`26341`).


==========================

1.9.5

Not secure
==========================

*April 1, 2016*

Django 1.9.5 fixes several bugs in 1.9.4.

Bugfixes
========

* Made ``MultiPartParser`` ignore filenames that normalize to an empty string
to fix crash in ``MemoryFileUploadHandler`` on specially crafted user input
(:ticket:`26325`).

* Fixed a race condition in ``BaseCache.get_or_set()`` (:ticket:`26332`). It
now returns the ``default`` value instead of ``False`` if there's an error
when trying to add the value to the cache.

* Fixed data loss on SQLite where ``DurationField`` values with fractional
seconds could be saved as ``None`` (:ticket:`26324`).

* The forms in ``contrib.auth`` no longer strip trailing and leading whitespace
from the password fields (:ticket:`26334`). The change requires users who set
their password to something with such whitespace after a site updated to
Django 1.9 to reset their password. It provides backwards-compatibility for
earlier versions of Django.

* Fixed a memory leak in the cached template loader (:ticket:`26306`).

* Fixed a regression that caused ``collectstatic --clear`` to fail if the
storage doesn't implement ``path()`` (:ticket:`26297`).

* Fixed a crash when using a reverse lookup with a subquery when a
``ForeignKey`` has a ``to_field`` set to something other than the primary key
(:ticket:`26373`).

* Fixed a regression in ``CommonMiddleware`` that caused spurious warnings in
logs on requests missing a trailing slash (:ticket:`26293`).

* Restored the functionality of the admin's ``raw_id_fields`` in
``list_editable`` (:ticket:`26387`).

* Fixed a regression with abstract model inheritance and explicit parent links
(:ticket:`26413`).

* Fixed a migrations crash on SQLite when renaming the primary key of a model
containing a ``ForeignKey`` to ``'self'`` (:ticket:`26384`).

* Fixed ``JSONField`` inadvertently escaping its contents when displaying values
after failed form validation (:ticket:`25532`).


==========================

1.9.4

Not secure
==========================

*March 5, 2016*

Django 1.9.4 fixes a regression on Python 2 in the 1.9.3 security release
where ``utils.http.is_safe_url()`` crashes on bytestring URLs (:ticket:`26308`).


==========================

1.9.3

Not secure
==========================

*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 :doc:`i18n </topics/i18n/index>`)
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 :ref:`third-party password hashers that don't
implement <write-your-own-password-hasher>` 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 :ref:`upgrade those hashes
<wrapping-password-hashers>` to prevent a timing attack for that case.

Bugfixes
========

* Skipped URL checks (new in 1.9) if the ``ROOT_URLCONF`` setting isn't defined
(:ticket:`26155`).

* Fixed a crash on PostgreSQL that prevented using ``TIME_ZONE=None`` and
``USE_TZ=False`` (:ticket:`26177`).

* Added system checks for query name clashes of hidden relationships
(:ticket:`26162`).

* Fixed a regression for cases where
``ForeignObject.get_extra_descriptor_filter()`` returned a ``Q`` object
(:ticket:`26153`).

* Fixed regression with an ``__in=qs`` lookup for a ``ForeignKey`` with
``to_field`` set (:ticket:`26196`).

* Made ``forms.FileField`` and ``utils.translation.lazy_number()`` picklable
(:ticket:`26212`).

* Fixed :class:`~django.contrib.postgres.fields.RangeField` and
:class:`~django.contrib.postgres.fields.ArrayField` serialization with
``None`` values (:ticket:`26215`).

* Fixed a crash when filtering by a ``Decimal`` in ``RawQuery``
(:ticket:`26219`).

* Reallowed dashes in top-level domain names of URLs checked by
``URLValidator`` to fix a regression in Django 1.8 (:ticket:`26204`).

* Fixed some crashing deprecation shims in ``SimpleTemplateResponse`` that
regressed in Django 1.9 (:ticket:`26253`).

* Fixed ``BoundField`` to reallow slices of subwidgets (:ticket:`26267`).

* Changed the admin's "permission denied" message in the login template to use
``get_username`` instead of ``username`` to support custom user models
(:ticket:`26231`).

* Fixed a crash when passing a nonexistent template name to the cached template
loader's ``load_template()`` method (:ticket:`26280`).

* Prevented ``ContentTypeManager`` instances from sharing their cache
(:ticket:`26286`).

* Reverted a change in Django 1.9.2 (:ticket:`25858`) that prevented relative
lazy relationships defined on abstract models to be resolved according to
their concrete model's ``app_label`` (:ticket:`26186`).


==========================

Page 34 of 52

Links

Releases

Has known vulnerabilities

© 2024 Safety CLI Cybersecurity Inc. All Rights Reserved.