July 8, 2015
\nDjango 1.7.9 fixes several security issues and bugs in 1.7.8.
\nIn previous versions of Django, the session backends created a new empty record\nin the session storage anytime request.session was accessed and there was a\nsession key provided in the request cookies that didn’t already have a session\nrecord. This could allow an attacker to easily create many new session records\nsimply by sending repeated requests with unknown session keys, potentially\nfilling up the session store or causing other users’ session records to be\nevicted.
The built-in session backends now create a session record only if the session\nis actually modified; empty session records are not created. Thus this\npotential DoS is now only possible if the site chooses to expose a\nsession-modifying view to anonymous users.
\nAs each built-in session backend was fixed separately (rather than a fix in the\ncore sessions framework), maintainers of third-party session backends should\ncheck whether the same vulnerability is present in their backend and correct\nit if so.
\nSome of Django’s built-in validators\n(EmailValidator, most seriously) didn’t\nprohibit newline characters (due to the usage of $ instead of \\Z in the\nregular expressions). If you use values with newlines in HTTP response or email\nheaders, you can suffer from header injection attacks. Django itself isn’t\nvulnerable because HttpResponse and the mail sending\nutilities in django.core.mail prohibit newlines in HTTP and SMTP\nheaders, respectively. While the validators have been fixed in Django, if\nyou’re creating HTTP responses or email messages in other ways, it’s a good\nidea to ensure that those methods prohibit newlines as well. You might also\nwant to validate that any existing data in your application doesn’t contain\nunexpected newlines.
validate_ipv4_address(),\nvalidate_slug(), and\nURLValidator are also affected, however, as\nof Django 1.6 the GenericIPAddresseField, IPAddressField,\nSlugField, and URLField form fields which use these validators all\nstrip the input, so the possibility of newlines entering your data only exists\nif you are using these validators outside of the form fields.
The undocumented, internally unused validate_integer() function is now\nstricter as it validates using a regular expression instead of simply casting\nthe value using int() and checking if an exception was raised.