Fixed #19324 -- Avoided creating a session record when loading the session.

The session record is now only created if/when the session is modified. This
prevents a potential DoS via creation of many empty session records.

This is a security fix; disclosure to follow shortly.

3 files changed, 63 insertions, 0 deletions

diff --git a/docs/releases/1.4.21.txt b/docs/releases/1.4.21.txt
index 6ff4c6d115..da69b26564 100644
--- a/docs/releases/1.4.21.txt
+++ b/docs/releases/1.4.21.txt
@@ -5,3 +5,24 @@ Django 1.4.21 release notes
 *July 8, 2015*
 
 Django 1.4.21 fixes several security issues in 1.4.20.
+
+Denial-of-service possibility by filling session store
+======================================================
+
+In previous versions of Django, the session backends created a new empty record
+in the session storage anytime ``request.session`` was accessed and there was a
+session key provided in the request cookies that didn't already have a session
+record. This could allow an attacker to easily create many new session records
+simply by sending repeated requests with unknown session keys, potentially
+filling up the session store or causing other users' session records to be
+evicted.
+
+The built-in session backends now create a session record only if the session
+is actually modified; empty session records are not created. Thus this
+potential DoS is now only possible if the site chooses to expose a
+session-modifying view to anonymous users.
+
+As each built-in session backend was fixed separately (rather than a fix in the
+core sessions framework), maintainers of third-party session backends should
+check whether the same vulnerability is present in their backend and correct
+it if so.
diff --git a/docs/releases/1.7.9.txt b/docs/releases/1.7.9.txt
index a2101ad6f9..f402a4cdd5 100644
--- a/docs/releases/1.7.9.txt
+++ b/docs/releases/1.7.9.txt
@@ -6,6 +6,27 @@ Django 1.7.9 release notes
 
 Django 1.7.9 fixes several security issues and bugs in 1.7.8.
 
+Denial-of-service possibility by filling session store
+======================================================
+
+In previous versions of Django, the session backends created a new empty record
+in the session storage anytime ``request.session`` was accessed and there was a
+session key provided in the request cookies that didn't already have a session
+record. This could allow an attacker to easily create many new session records
+simply by sending repeated requests with unknown session keys, potentially
+filling up the session store or causing other users' session records to be
+evicted.
+
+The built-in session backends now create a session record only if the session
+is actually modified; empty session records are not created. Thus this
+potential DoS is now only possible if the site chooses to expose a
+session-modifying view to anonymous users.
+
+As each built-in session backend was fixed separately (rather than a fix in the
+core sessions framework), maintainers of third-party session backends should
+check whether the same vulnerability is present in their backend and correct
+it if so.
+
 Bugfixes
 ========
 
diff --git a/docs/releases/1.8.3.txt b/docs/releases/1.8.3.txt
index aa6e46a99c..c2283048a5 100644
--- a/docs/releases/1.8.3.txt
+++ b/docs/releases/1.8.3.txt
@@ -11,6 +11,27 @@ Also, ``django.utils.deprecation.RemovedInDjango20Warning`` was renamed to
 1.11 (LTS), 2.0 (drops Python 2 support). For backwards compatibility,
 ``RemovedInDjango20Warning`` remains as an importable alias.
 
+Denial-of-service possibility by filling session store
+======================================================
+
+In previous versions of Django, the session backends created a new empty record
+in the session storage anytime ``request.session`` was accessed and there was a
+session key provided in the request cookies that didn't already have a session
+record. This could allow an attacker to easily create many new session records
+simply by sending repeated requests with unknown session keys, potentially
+filling up the session store or causing other users' session records to be
+evicted.
+
+The built-in session backends now create a session record only if the session
+is actually modified; empty session records are not created. Thus this
+potential DoS is now only possible if the site chooses to expose a
+session-modifying view to anonymous users.
+
+As each built-in session backend was fixed separately (rather than a fix in the
+core sessions framework), maintainers of third-party session backends should
+check whether the same vulnerability is present in their backend and correct
+it if so.
+
 Bugfixes
 ========