Django

Latest version: v5.0.3

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

Scan your dependencies

Page 41 of 52

1.6.9

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

*January 2, 2015*

Django 1.6.9 fixes a regression in the 1.6.6 security release.

Additionally, Django's vendored version of six, ``django.utils.six``, has
been upgraded to the latest release (1.9.0).

Bugfixes
========

* Fixed a regression with dynamically generated inlines and allowed field
references in the admin (:ticket:`23754`).


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

1.6.8

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

*October 22, 2014*

Django 1.6.8 fixes a couple regressions in the 1.6.6 security release.

Bugfixes
========

* Allowed related many-to-many fields to be referenced in the admin
(:ticket:`23604`).

* Allowed inline and hidden references to admin fields (:ticket:`23431`).


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

1.6.7

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

*September 2, 2014*

Django 1.6.7 fixes several bugs in 1.6.6, including a regression related to
a security fix in that release.

Bugfixes
========

* Allowed inherited and m2m fields to be referenced in the admin
(:ticket:`23329`).
* Fixed a crash when using ``QuerySet.defer()`` with ``select_related()``
(:ticket:`23370`).


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

1.6.6

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

*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.
:meth:`Storage.get_available_name()
<django.core.files.storage.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 :class:`~django.contrib.auth.middleware.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
(:ticket:`22579`).

* Prevented indexes on PostgreSQL virtual fields (:ticket:`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 (:ticket:`13794`).

* Restored ``pre_delete`` signals for ``GenericRelation`` cascade deletion
(:ticket:`22998`).

* Fixed transaction handling when specifying non-default database in
``createcachetable`` and ``flush`` (:ticket:`23089`).

* Fixed the "ORA-01843: not a valid month" errors when using Unicode
with older versions of Oracle server (:ticket:`20292`).

* Restored bug fix for sending Unicode email with Python 2.6.5 and below
(:ticket:`19107`).

* Prevented ``UnicodeDecodeError`` in ``runserver`` with non-UTF-8 and
non-English locale (:ticket:`23265`).

* Fixed JavaScript errors while editing multi-geometry objects in the OpenLayers
widget (:ticket:`23137`, :ticket:`23293`).

* Prevented a crash on Python 3 with query strings containing unencoded
non-ASCII characters (:ticket:`22996`).


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

1.6.5

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

*May 14, 2014*

Django 1.6.5 fixes two security issues and several bugs in 1.6.4.

Issue: Caches may incorrectly be allowed to store and serve private data
========================================================================

In certain situations, Django may allow caches to store private data
related to a particular session and then serve that data to requests
with a different session, or no session at all. This can lead to
information disclosure and can be a vector for cache poisoning.

When using Django sessions, Django will set a ``Vary: Cookie`` header to
ensure caches do not serve cached data to requests from other sessions.
However, older versions of Internet Explorer (most likely only Internet
Explorer 6, and Internet Explorer 7 if run on Windows XP or Windows Server
2003) are unable to handle the ``Vary`` header in combination with many content
types. Therefore, Django would remove the header if the request was made by
Internet Explorer.

To remedy this, the special behavior for these older Internet Explorer versions
has been removed, and the ``Vary`` header is no longer stripped from the response.
In addition, modifications to the ``Cache-Control`` header for all Internet Explorer
requests with a ``Content-Disposition`` header have also been removed as they
were found to have similar issues.

Issue: Malformed redirect URLs from user input not correctly validated
======================================================================

The validation for redirects did not correctly validate some malformed URLs,
which are accepted by some browsers. This allows a user to be redirected to
an unsafe URL unexpectedly.

Django relies on user input in some cases (e.g.
``django.contrib.auth.views.login()``, ``django.contrib.comments``, and
:doc:`i18n </topics/i18n/index>`) to redirect the user to an "on success" URL.
The security checks for these redirects (namely
``django.utils.http.is_safe_url()``) did not correctly validate some malformed
URLs, such as ``http:\\\\\\djangoproject.com``, which are accepted by some
browsers with more liberal URL parsing.

To remedy this, the validation in ``is_safe_url()`` has been tightened to be able
to handle and correctly validate these malformed URLs.

Bugfixes
========

* Made the ``year_lookup_bounds_for_datetime_field`` Oracle backend method
Python 3 compatible (:ticket:`22551`).

* Fixed ``pgettext_lazy`` crash when receiving bytestring content on Python 2
(:ticket:`22565`).

* Fixed the SQL generated when filtering by a negated ``Q`` object that contains
a ``F`` object. (:ticket:`22429`).

* Avoided overwriting data fetched by ``select_related()`` in certain cases
which could cause minor performance regressions
(:ticket:`22508`).


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

1.6.4

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

*April 28, 2014*

Django 1.6.4 fixes several bugs in 1.6.3.

Bugfixes
========

* Added backwards compatibility support for the :mod:`django.contrib.messages`
cookie format of Django 1.4 and earlier to facilitate upgrading to 1.6 from
1.4 (:ticket:`22426`).

* Restored the ability to ``reverse()`` views created using
:func:`functools.partial()` (:ticket:`22486`).

* Fixed the ``object_id`` of the ``LogEntry`` that's created after a user
password change in the admin (:ticket:`22515`).


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

Page 41 of 52

Links

Releases

Has known vulnerabilities

© 2024 Safety CLI Cybersecurity Inc. All Rights Reserved.