January 13, 2015
\nDjango 1.4.18 fixes several security issues in 1.4.17 as well as a regression\non Python 2.5 in the 1.4.17 release.
\nWhen HTTP headers are placed into the WSGI environ, they are normalized by\nconverting to uppercase, converting all dashes to underscores, and prepending\nHTTP_. For instance, a header X-Auth-User would become\nHTTP_X_AUTH_USER in the WSGI environ (and thus also in Django’s\nrequest.META dictionary).
Unfortunately, this means that the WSGI environ cannot distinguish between\nheaders containing dashes and headers containing underscores: X-Auth-User\nand X-Auth_User both become HTTP_X_AUTH_USER. This means that if a\nheader is used in a security-sensitive way (for instance, passing\nauthentication information along from a front-end proxy), even if the proxy\ncarefully strips any incoming value for X-Auth-User, an attacker may be\nable to provide an X-Auth_User header (with underscore) and bypass this\nprotection.
In order to prevent such attacks, both Nginx and Apache 2.4+ strip all headers\ncontaining underscores from incoming requests by default. Django’s built-in\ndevelopment server now does the same. Django’s development server is not\nrecommended for production use, but matching the behavior of common production\nservers reduces the surface area for behavior changes during deployment.
\nDjango relies on user input in some cases (e.g.\ndjango.contrib.auth.views.login() and i18n)\nto redirect the user to an “on success” URL. The security checks for these\nredirects (namely django.utils.http.is_safe_url()) didn’t strip leading\nwhitespace on the tested URL and as such considered URLs like\n\\njavascript:... safe. If a developer relied on is_safe_url() to\nprovide safe redirect targets and put such a URL into a link, they could suffer\nfrom a XSS attack. This bug doesn’t affect Django currently, since we only put\nthis URL into the Location response header and browsers seem to ignore\nJavaScript there.
django.views.static.serveLink to this heading#In older versions of Django, the django.views.static.serve() view read\nthe files it served one line at a time. Therefore, a big file with no newlines\nwould result in memory usage equal to the size of that file. An attacker could\nexploit this and launch a denial-of-service attack by simultaneously requesting\nmany large files. This view now reads the file in chunks to prevent large\nmemory usage.
Note, however, that this view has always carried a warning that it is not\nhardened for production use and should be used only as a development aid. Now\nmay be a good time to audit your project and serve your files in production\nusing a real front-end web server if you are not doing so.
\nTo maintain compatibility with Python 2.5, Django’s vendored version of six,\ndjango.utils.six, has been downgraded to 1.8.0 which is the last\nversion to support Python 2.5.