Django

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

*January 13, 2015*

Django 1.4.18 fixes several security issues in 1.4.17 as well as a regression
on Python 2.5 in the 1.4.17 release.

WSGI header spoofing via underscore/dash conflation
===================================================

When HTTP headers are placed into the WSGI environ, they are normalized by
converting to uppercase, converting all dashes to underscores, and prepending
``HTTP_``. For instance, a header ``X-Auth-User`` would become
``HTTP_X_AUTH_USER`` in the WSGI environ (and thus also in Django's
``request.META`` dictionary).

Unfortunately, this means that the WSGI environ cannot distinguish between
headers containing dashes and headers containing underscores: ``X-Auth-User``
and ``X-Auth_User`` both become ``HTTP_X_AUTH_USER``. This means that if a
header is used in a security-sensitive way (for instance, passing
authentication information along from a front-end proxy), even if the proxy
carefully strips any incoming value for ``X-Auth-User``, an attacker may be
able to provide an ``X-Auth_User`` header (with underscore) and bypass this
protection.

In order to prevent such attacks, both Nginx and Apache 2.4+ strip all headers
containing underscores from incoming requests by default. Django's built-in
development server now does the same. Django's development server is not
recommended for production use, but matching the behavior of common production
servers reduces the surface area for behavior changes during deployment.

Mitigated possible XSS attack via user-supplied redirect URLs
=============================================================

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 checks for these
redirects (namely ``django.utils.http.is_safe_url()``) didn't strip leading
whitespace on the tested URL and as such considered URLs like
``\njavascript:...`` safe. If a developer relied on ``is_safe_url()`` to
provide safe redirect targets and put such a URL into a link, they could suffer
from a XSS attack. This bug doesn't affect Django currently, since we only put
this URL into the ``Location`` response header and browsers seem to ignore
JavaScript there.

Denial-of-service attack against ``django.views.static.serve``
==============================================================

In older versions of Django, the :func:`django.views.static.serve` view read
the files it served one line at a time. Therefore, a big file with no newlines
would result in memory usage equal to the size of that file. An attacker could
exploit this and launch a denial-of-service attack by simultaneously requesting
many large files. This view now reads the file in chunks to prevent large
memory usage.

Note, however, that this view has always carried a warning that it is not
hardened for production use and should be used only as a development aid. Now
may be a good time to audit your project and serve your files in production
using a real front-end web server if you are not doing so.

Bugfixes
========

* To maintain compatibility with Python 2.5, Django's vendored version of six,
``django.utils.six``, has been downgraded to 1.8.0 which is the last
version to support Python 2.5.


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

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

*January 2, 2015*

Django 1.4.17 fixes a regression in the 1.4.14 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`).


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

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

*October 22, 2014*

Django 1.4.16 fixes a couple regressions in the 1.4.14 security release and a
bug preventing the use of some GEOS versions with GeoDjango.

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`).

* Fixed parsing of the GEOS version string
(:ticket:`20036`).


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

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

*September 2, 2014*

Django 1.4.15 fixes a regression in the 1.4.14 security release.

Bugfixes
========

* Allowed inherited and m2m fields to be referenced in the admin
(:ticket:`22486`)


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

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

*August 20, 2014*

Django 1.4.14 fixes several security issues in 1.4.13.

``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/?pop=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.


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

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

*May 14, 2014*

Django 1.4.13 fixes two security issues in 1.4.12.

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.

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.


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