From df049ed77a4db67e45db5679bfc76a85d2a26680 Mon Sep 17 00:00:00 2001 From: Carl Meyer Date: Wed, 10 Jun 2015 15:45:20 -0600 Subject: 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. --- docs/releases/1.4.21.txt | 21 +++++++++++++++++++++ docs/releases/1.7.9.txt | 21 +++++++++++++++++++++ docs/releases/1.8.3.txt | 21 +++++++++++++++++++++ 3 files changed, 63 insertions(+) (limited to 'docs') 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 ======== -- cgit v1.3