1.5.3.txt 2.4 KB

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