1
==========================
2
Django 1.7.9 release notes
3
==========================
7
Django 1.7.9 fixes several security issues and bugs in 1.7.8.
9
Denial-of-service possibility by filling session store
10
======================================================
12
In previous versions of Django, the session backends created a new empty record
13
in the session storage anytime ``request.session`` was accessed and there was a
14
session key provided in the request cookies that didn't already have a session
15
record. This could allow an attacker to easily create many new session records
16
simply by sending repeated requests with unknown session keys, potentially
17
filling up the session store or causing other users' session records to be
20
The built-in session backends now create a session record only if the session
21
is actually modified; empty session records are not created. Thus this
22
potential DoS is now only possible if the site chooses to expose a
23
session-modifying view to anonymous users.
25
As each built-in session backend was fixed separately (rather than a fix in the
26
core sessions framework), maintainers of third-party session backends should
27
check whether the same vulnerability is present in their backend and correct
30
Header injection possibility since validators accept newlines in input
31
======================================================================
33
Some of Django's built-in validators
34
(:class:`~django.core.validators.EmailValidator`, most seriously) didn't
35
prohibit newline characters (due to the usage of ``$`` instead of ``\Z`` in the
36
regular expressions). If you use values with newlines in HTTP response or email
37
headers, you can suffer from header injection attacks. Django itself isn't
38
vulnerable because :class:`~django.http.HttpResponse` and the mail sending
39
utilities in :mod:`django.core.mail` prohibit newlines in HTTP and SMTP
40
headers, respectively. While the validators have been fixed in Django, if
41
you're creating HTTP responses or email messages in other ways, it's a good
42
idea to ensure that those methods prohibit newlines as well. You might also
43
want to validate that any existing data in your application doesn't contain
46
:func:`~django.core.validators.validate_ipv4_address`,
47
:func:`~django.core.validators.validate_slug`, and
48
:class:`~django.core.validators.URLValidator` are also affected, however, as
49
of Django 1.6 the ``GenericIPAddresseField``, ``IPAddressField``, ``SlugField``,
50
and ``URLField`` form fields which use these validators all strip the input, so
51
the possibility of newlines entering your data only exists if you are using
52
these validators outside of the form fields.
54
The undocumented, internally unused ``validate_integer()`` function is now
55
stricter as it validates using a regular expression instead of simply casting
56
the value using ``int()`` and checking if an exception was raised.
61
* Prevented the loss of ``null``/``not null`` column properties during field
62
renaming of MySQL databases (:ticket:`24817`).
64
* Fixed ``SimpleTestCase.assertRaisesMessage()`` on Python 2.7.10
added
removed
docs/releases/1.7.9.txt
