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

[1.5.x] Added a warning regarding session security and subdomains.

Browse Source 
Backport of a3372f67cb from master
This commit is contained in:
Tim Graham
2013-09-25 12:59:33 -04:00
parent 0fb2897c81
commit 472917024b
2 changed files with 35 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

30
docs/topics/http/sessions.txt
View File

@@ -299,13 +299,19 @@ You can edit it multiple times.
Returns either ``True`` or ``False``, depending on whether the user's Returns either ``True`` or ``False``, depending on whether the user's
session cookie will expire when the user's Web browser is closed. session cookie will expire when the user's Web browser is closed.
.. method:: SessionBase.clear_expired .. method:: clear_expired
.. versionadded:: 1.5 .. versionadded:: 1.5
Removes expired sessions from the session store. This class method is Removes expired sessions from the session store. This class method is
called by :djadmin:`clearsessions`. called by :djadmin:`clearsessions`.
.. method:: cycle_key
Creates a new session key while retaining the current session data.
:func:`django.contrib.auth.login()` calls this method to mitigate against
session fixation.
.. _session_serialization: .. _session_serialization:
Session serialization Session serialization
@@ -486,7 +492,7 @@ An API is available to manipulate session data outside of a view::
>>> s['last_login'] >>> s['last_login']
1376587691 1376587691
In order to prevent session fixation attacks, sessions keys that don't exist In order to mitigate session fixation attacks, sessions keys that don't exist
are regenerated:: are regenerated::
>>> from django.contrib.sessions.backends.db import SessionStore >>> from django.contrib.sessions.backends.db import SessionStore
@@ -720,6 +726,26 @@ that is, if any of its dictionary values have been assigned or deleted.
.. _Django settings: ../settings/ .. _Django settings: ../settings/
.. _topics-session-security:
Session security
================
Subdomains within a site are able to set cookies on the client for the whole
domain. This makes session fixation possible if all subdomains are not
controlled by trusted users (or, are at least unable to set cookies).
For example, an attacker could log into ``good.example.com`` and get a valid
session for his account. If the attacker has control over ``bad.example.com``,
he can use it to send his session key to you since a subdomain is permitted
to set cookies on `*.example.com``. When you visit ``good.example.com``,
you'll be logged in as the attacker and might inadvertently enter your
sensitive personal data (e.g. credit card info) into the attackers account.
Another possible attack would be if ``good.example.com`` sets its
:setting:`SESSION_COOKIE_DOMAIN` to ``".example.com"`` which would cause
session cookies from that site to be sent to ``bad.example.com``.
Technical details Technical details
================= =================

7
docs/topics/security.txt
View File

@@ -202,6 +202,13 @@ Additionally, as of 1.3.1, Django requires you to explicitly enable support for
the ``X-Forwarded-Host`` header (via the :setting:`USE_X_FORWARDED_HOST` the ``X-Forwarded-Host`` header (via the :setting:`USE_X_FORWARDED_HOST`
setting) if your configuration requires it. setting) if your configuration requires it.
Session security
================
Similar to the :ref:`CSRF limitations <csrf-limitations>` requiring a site to
be deployed such that untrusted users don't have access to any subdomains,
:mod:`django.contrib.sessions` also has limitations. See :ref:`the session
topic guide section on security <topics-session-security>` for details.
.. _additional-security-topics: .. _additional-security-topics: