django/docs/releases/1.5.3.txt

51 lines
2.4 KiB
Plaintext
Raw Normal View History

2013-08-23 10:49:37 +00:00
==========================
Django 1.5.3 release notes
==========================
*September 10, 2013*
This is Django 1.5.3, the third release in the Django 1.5 series. It addresses
one security issue and also contains an opt-in feature to enhance the security
of :mod:`django.contrib.sessions`.
Directory traversal vulnerability in ``ssi`` template tag
=========================================================
2013-08-23 10:49:37 +00:00
In previous versions of Django it was possible to bypass the
``ALLOWED_INCLUDE_ROOTS`` setting used for security with the ``ssi``
2013-08-23 10:49:37 +00:00
template tag by specifying a relative path that starts with one of the allowed
roots. For example, if ``ALLOWED_INCLUDE_ROOTS = ("/var/www",)`` the following
would be possible:
.. code-block:: html+django
{% ssi "/var/www/../../etc/passwd" %}
In practice this is not a very common problem, as it would require the template
author to put the ``ssi`` file in a user-controlled variable, but it's possible
in principle.
2013-08-23 10:49:37 +00:00
Mitigating a remote-code execution vulnerability in :mod:`django.contrib.sessions`
==================================================================================
2013-08-23 10:49:37 +00:00
:mod:`django.contrib.sessions` currently uses :mod:`pickle` to serialize
session data before storing it in the backend. If you're using the :ref:`signed
cookie session backend<cookie-session-backend>` and :setting:`SECRET_KEY` is
known by an attacker (there isn't an inherent vulnerability in Django that
would cause it to leak), the attacker could insert a string into their session
2013-08-23 10:49:37 +00:00
which, when unpickled, executes arbitrary code on the server. The technique for
doing so is simple and easily available on the internet. Although the cookie
session storage signs the cookie-stored data to prevent tampering, a
:setting:`SECRET_KEY` leak immediately escalates to a remote code execution
vulnerability.
This attack can be mitigated by serializing session data using JSON rather
than :mod:`pickle`. To facilitate this, Django 1.5.3 introduces a new setting,
:setting:`SESSION_SERIALIZER`, to customize the session serialization format.
For backwards compatibility, this setting defaults to using :mod:`pickle`.
While JSON serialization does not support all Python objects like :mod:`pickle`
does, we highly recommend switching to JSON-serialized values. Also,
as JSON requires string keys, you will likely run into problems if you are
using non-string keys in ``request.session``. See the
:ref:`session_serialization` documentation for more details.