summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorTim Graham <timograham@gmail.com>2013-10-02 10:15:18 -0400
committerTim Graham <timograham@gmail.com>2013-10-02 10:15:36 -0400
commit9b89fcc0b0c85dad5034b048e436f06a981f28e8 (patch)
tree8603832768c24128d630836d65cb7f52d5ec25c9
parentdc26f3fc9bb1385c483637c04f0dca04b42fcfcb (diff)
[1.6.x] Clarified session replay attack differences with cookie backend.
Backport of 00a0d3de02 from master
-rw-r--r--docs/topics/http/sessions.txt8
1 files changed, 6 insertions, 2 deletions
diff --git a/docs/topics/http/sessions.txt b/docs/topics/http/sessions.txt
index c71bc09c35..92e5c6622e 100644
--- a/docs/topics/http/sessions.txt
+++ b/docs/topics/http/sessions.txt
@@ -162,8 +162,12 @@ and the :setting:`SECRET_KEY` setting.
integrity of the data (that it is all there and correct), it cannot
guarantee freshness i.e. that you are being sent back the last thing you
sent to the client. This means that for some uses of session data, the
- cookie backend might open you up to `replay attacks`_. Cookies will only be
- detected as 'stale' if they are older than your
+ cookie backend might open you up to `replay attacks`_. Unlike other session
+ backends which keep a server-side record of each session and invalidate it
+ when a user logs out, cookie-based sessions are not invalidated when a user
+ logs out. Thus if an attacker steals a user's cookie, he can use that
+ cookie to login as that user even if the user logs out. Cookies will only
+ be detected as 'stale' if they are older than your
:setting:`SESSION_COOKIE_AGE`.
**Performance**