=============================
Django 1.6.11.1 release notes
=============================

*August 18, 2015*

Django 1.6.11.1 fixes all known security issues since the release of Django
1.6.11, up through this release.


Denial-of-service possibility by filling session store
======================================================

In previous versions of Django, the session backends created a new empty
record in the session storage anytime ``request.session`` was accessed and
there was a session key provided in the request cookies that didn't already
have a session record. This could allow an attacker to easily create many new
session records simply by sending repeated requests with unknown session keys,
potentially filling up the session store or causing other users' session
records to be evicted.

The built-in session backends now create a session record only if the session
is actually modified; empty session records are not created. Thus this
potential DoS is now only possible if the site chooses to expose a
session-modifying view to anonymous users.

As each built-in session backend was fixed separately (rather than a fix in
the core sessions framework), maintainers of third-party session backends
should check whether the same vulnerability is present in their backend and
correct it if so.


Header injection possibility since validators accept newlines in input
======================================================================

Some of Django's built-in validators
(:class:`~django.core.validators.EmailValidator`, most seriously) didn't
prohibit newline characters (due to the usage of ``$`` instead of ``\Z`` in
the regular expressions). If you use values with newlines in HTTP response or
email headers, you can suffer from header injection attacks. Django itself
isn't vulnerable because :class:`~django.http.HttpResponse` and the mail
sending utilities in :mod:`django.core.mail` prohibit newlines in HTTP and
SMTP headers, respectively. While the validators have been fixed in Django, if
you're creating HTTP responses or email messages in other ways, it's a good
idea to ensure that those methods prohibit newlines as well. You might also
want to validate that any existing data in your application doesn't contain
unexpected newlines.

:func:`~django.core.validators.validate_ipv4_address`,
:func:`~django.core.validators.validate_slug`, and
:class:`~django.core.validators.URLValidator` and their usage in the
corresponding form fields ``GenericIPAddresseField``, ``IPAddressField``,
``SlugField``, and ``URLField`` are also affected.

The undocumented, internally unused ``validate_integer()`` function is now
stricter as it validates using a regular expression instead of simply casting
the value using ``int()`` and checking if an exception was raised.


Denial-of-service possibility in ``logout()`` view by filling session store
===========================================================================

Previously, a session could be created when anonymously accessing the
:func:`django.contrib.auth.views.logout` view (provided it wasn't decorated
with :func:`~django.contrib.auth.decorators.login_required` as done in the
admin). This could allow an attacker to easily create many new session records
by sending repeated requests, potentially filling up the session store or
causing other users' session records to be evicted.

The :class:`~django.contrib.sessions.middleware.SessionMiddleware` has been
modified to no longer create empty session records.

Additionally, the ``contrib.sessions.backends.base.SessionBase.flush()`` and
``cache_db.SessionStore.flush()`` methods have been modified to avoid creating
a new empty session. Maintainers of third-party session backends should check
if the same vulnerability is present in their backend and correct it if so.
