1. ===========================

  2. Django 1.4.18 release notes

  3. ===========================

  4. 

  5. *January 13, 2015*

  6. 

  7. Django 1.4.18 fixes several security issues in 1.4.17 as well as a regression

  8. on Python 2.5 in the 1.4.17 release.

  9. 

  10. WSGI header spoofing via underscore/dash conflation

  11. ===================================================

  12. 

  13. When HTTP headers are placed into the WSGI environ, they are normalized by

  14. converting to uppercase, converting all dashes to underscores, and prepending

  15. ``HTTP_``. For instance, a header ``X-Auth-User`` would become

  16. ``HTTP_X_AUTH_USER`` in the WSGI environ (and thus also in Django's

  17. ``request.META`` dictionary).

  18. 

  19. Unfortunately, this means that the WSGI environ cannot distinguish between

  20. headers containing dashes and headers containing underscores: ``X-Auth-User``

  21. and ``X-Auth_User`` both become ``HTTP_X_AUTH_USER``. This means that if a

  22. header is used in a security-sensitive way (for instance, passing

  23. authentication information along from a front-end proxy), even if the proxy

  24. carefully strips any incoming value for ``X-Auth-User``, an attacker may be

  25. able to provide an ``X-Auth_User`` header (with underscore) and bypass this

  26. protection.

  27. 

  28. In order to prevent such attacks, both Nginx and Apache 2.4+ strip all headers

  29. containing underscores from incoming requests by default. Django's built-in

  30. development server now does the same. Django's development server is not

  31. recommended for production use, but matching the behavior of common production

  32. servers reduces the surface area for behavior changes during deployment.

  33. 

  34. Mitigated possible XSS attack via user-supplied redirect URLs

  35. =============================================================

  36. 

  37. Django relies on user input in some cases (e.g.

  38. ``django.contrib.auth.views.login()`` and :doc:`i18n </topics/i18n/index>`)

  39. to redirect the user to an "on success" URL. The security checks for these

  40. redirects (namely ``django.utils.http.is_safe_url()``) didn't strip leading

  41. whitespace on the tested URL and as such considered URLs like

  42. ``\njavascript:...`` safe. If a developer relied on ``is_safe_url()`` to

  43. provide safe redirect targets and put such a URL into a link, they could suffer

  44. from a XSS attack. This bug doesn't affect Django currently, since we only put

  45. this URL into the ``Location`` response header and browsers seem to ignore

  46. JavaScript there.

  47. 

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

  49. ==============================================================

  50. 

  51. In older versions of Django, the :func:`django.views.static.serve` view read

  52. the files it served one line at a time. Therefore, a big file with no newlines

  53. would result in memory usage equal to the size of that file. An attacker could

  54. exploit this and launch a denial-of-service attack by simultaneously requesting

  55. many large files. This view now reads the file in chunks to prevent large

  56. memory usage.

  57. 

  58. Note, however, that this view has always carried a warning that it is not

  59. hardened for production use and should be used only as a development aid. Now

  60. may be a good time to audit your project and serve your files in production

  61. using a real front-end web server if you are not doing so.

  62. 

  63. Bugfixes

  64. ========

  65. 

  66. * To maintain compatibility with Python 2.5, Django's vendored version of six,

  67.   ``django.utils.six``, has been downgraded to 1.8.0 which is the last

  68.   version to support Python 2.5.
About Sign Up Leave Feedback Contact