#StackBounty: #django #session #cookies Django signed cookie session storage, replay attacks, and SESSION_COOKIE_AGE

Bounty: 50

As per the Django documentation, signed cookie session storage is vulnerable to a replay attack:

Note also that while the MAC can guarantee the authenticity of the
data (that it was generated by your site, and not someone else), and
the 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. 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, they 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 SESSION_COOKIE_AGE.

Does this mean that:

  1. We are relying on the client-side expiration of cookies to ensure that the session data is destroyed (thus a replay attack is still possible if the cookie contents are captured before the cookie is removed by the browser), or
  2. The server detects the staleness of the data (comparing with SESSION_COOKIE_AGE and explicitly rejects data it deems as stale.

It seems technically possible for Django to be able to determine how ‘old’ a session is without persisting this data server-side, but the docs don’t seem clear about whether or not this is being done, or is Django relying on / trusting the user’s browser to kill old cookies (and thus the session could still be replayed if the data was captured prior to its expiry).

Get this bounty!!!

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.