summaryrefslogtreecommitdiff
path: root/docs
diff options
context:
space:
mode:
authorCarl Meyer <carl@oddbird.net>2015-06-10 15:45:20 -0600
committerTim Graham <timograham@gmail.com>2015-07-08 07:38:06 -0400
commit2e47f3e401c29bc2ba5ab794d483cb0820855fb9 (patch)
tree69269e5672184425c13bb44ea4a6a6c5789ace81 /docs
parentc570a5ec3ef673eaad18dccb70bcda9f762e4354 (diff)
[1.4.x] 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.
Diffstat (limited to 'docs')
-rw-r--r--docs/releases/1.4.21.txt21
1 files changed, 21 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.