diff options
| author | Carl Meyer <carl@oddbird.net> | 2015-06-10 15:45:20 -0600 |
|---|---|---|
| committer | Tim Graham <timograham@gmail.com> | 2015-07-08 07:38:06 -0400 |
| commit | 2e47f3e401c29bc2ba5ab794d483cb0820855fb9 (patch) | |
| tree | 69269e5672184425c13bb44ea4a6a6c5789ace81 /docs | |
| parent | c570a5ec3ef673eaad18dccb70bcda9f762e4354 (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.txt | 21 |
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. |
