mirrors/django
1
0
Fork 0
mirror of https://github.com/django/django.git synced 2025-10-24 06:06:09 +00:00
Code Issues 32 Releases Wiki Activity

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

Browse Source 
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.
This commit is contained in:
Carl Meyer
2015-06-10 15:45:20 -06:00
committed by Tim Graham
parent 125eaa19b2
commit df049ed77a
8 changed files with 95 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files

21
docs/releases/1.4.21.txt
View File

@@ -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.

21
docs/releases/1.7.9.txt
View File

@@ -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
========

21
docs/releases/1.8.3.txt
View File

@@ -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
========