Django

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

*April 4, 2017*

Django 1.8.18 fixes two security issues in 1.8.17.

CVE-2017-7233: Open redirect and possible XSS attack via user-supplied numeric 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 check for these
redirects (namely ``django.utils.http.is_safe_url()``) considered some numeric
URLs (e.g. ``http:999999999``) "safe" when they shouldn't be.

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-2017-7234: Open redirect vulnerability in ``django.views.static.serve()``
=============================================================================

A maliciously crafted URL to a Django site using the
:func:`~django.views.static.serve` view could redirect to any other domain. The
view no longer does any redirects as they don't provide any known, useful
functionality.

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.


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

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

*December 1, 2016*

Django 1.8.17 fixes a regression in 1.8.16.

Bugfixes
========

* Quoted the Oracle test user's password in queries to fix the "ORA-00922:
missing or invalid option" error when the password starts with a number or
special character (:ticket:`27420`).


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

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

*November 1, 2016*

Django 1.8.16 fixes two security issues in 1.8.15.

User with hardcoded password created when running tests on Oracle
=================================================================

When running tests with an Oracle database, Django creates a temporary database
user. In older versions, if a password isn't manually specified in the database
settings ``TEST`` dictionary, a hardcoded password is used. This could allow
an attacker with network access to the database server to connect.

This user is usually dropped after the test suite completes, but not when using
the ``manage.py test --keepdb`` option or if the user has an active session
(such as an attacker's connection).

A randomly generated password is now used for each test run.

DNS rebinding vulnerability when ``DEBUG=True``
===============================================

Older versions of Django don't validate the ``Host`` header against
``settings.ALLOWED_HOSTS`` when ``settings.DEBUG=True``. This makes them
vulnerable to a `DNS rebinding attack
<https://benmmurphy.github.io/blog/2016/07/11/rails-webconsole-dns-rebinding/>`_.

While Django doesn't ship a module that allows remote code execution, this is
at least a cross-site scripting vector, which could be quite serious if
developers load a copy of the production database in development or connect to
some production services for which there's no development instance, for
example. If a project uses a package like the ``django-debug-toolbar``, then
the attacker could execute arbitrary SQL, which could be especially bad if the
developers connect to the database with a superuser account.

``settings.ALLOWED_HOSTS`` is now validated regardless of ``DEBUG``. For
convenience, if ``ALLOWED_HOSTS`` is empty and ``DEBUG=True``, the following
variations of localhost are allowed ``['localhost', '127.0.0.1', '::1']``. If
your local settings file has your production ``ALLOWED_HOSTS`` value, you must
now omit it to get those fallback values.


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

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

*September 26, 2016*

Django 1.8.15 fixes a security issue in 1.8.14.

CSRF protection bypass on a site with Google Analytics
======================================================

An interaction between Google Analytics and Django's cookie parsing could allow
an attacker to set arbitrary cookies leading to a bypass of CSRF protection.

The parser for ``request.COOKIES`` is simplified to better match the behavior
of browsers and to mitigate this attack. ``request.COOKIES`` may now contain
cookies that are invalid according to :rfc:`6265` but are possible to set via
``document.cookie``.


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

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

*July 18, 2016*

Django 1.8.14 fixes a security issue and a bug in 1.8.13.

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


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

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

*May 2, 2016*

Django 1.8.13 fixes several bugs in 1.8.12.

Bugfixes
========

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

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


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