#37249: Race condition can undo logout with cache/file session backends
-----------------------------+--------------------------------------------
Reporter: Shai Berger | Type: Bug
Status: new | Component: contrib.sessions
Version: dev | Severity: Normal
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-----------------------------+--------------------------------------------
Django’s cache and file session backends can resurrect a session that was
deleted by logout under a narrow but concrete concurrent-request race.
The vulnerable interleaving occurs when an authenticated same-session
request has already reached {{{SessionMiddleware.process_response()}}} and
the backend {{{save()}}} path has checked that the old session still
exists. If {{{/logout/}}} deletes that same session before the backend
performs its final write, the cache/file backend can write the old session
key again. {{{SessionMiddleware}}} then raises no {{{SessionInterrupted}}}
and sends {{{Set-Cookie}}} for the old {{{sessionid}}}.
This can restore authenticated session data after logout if the late
response is applied as the browser’s final cookie state.
The "signed_cookie", "db" and "cached_db" session backends are not
affected.
==== Root Cause
The DB session backend updates an existing row using
{{{force_update=True}}}. If logout deletes the row before a late save, the
update fails and Django
raises {{{UpdateError}}}, which {{{SessionMiddleware}}} converts to
{{{SessionInterrupted}}}.
The cache and file backends use a check-then-write pattern instead:
- Cache backend checks existence with {{{cache.get()}}} and then writes
with {{{cache.set()}}}.
- File backend checks that the target file exists, then writes a temporary
file and moves it into the target path.
Those final writes are not atomically tied to the existence check. If
logout deletes the same session after the check but before the final
write,
the old key/path is recreated instead of failing.
==== Failure Scenario
A user has an authenticated session, and two same-session requests are in
flight concurrently. This can occur through multiple tabs, background
requests, delayed form submissions, beacons/fetches, or application
endpoints that modify session state around the same time as logout.
The problematic interleaving is:
1. Request A modifies the session and reaches
{{{SessionMiddleware.process_response()}}}.
2. Request A’s backend {{{save()}}} path confirms the old session still
exists.
3. Request B calls {{{/logout/}}} and deletes the same session.
4. Request A performs its final backend write and recreates the old
session key.
5. Request A’s late response sends {{{Set-Cookie: sessionid=<old key>}}}.
6. If the browser applies Request A’s response after logout, a later
{{{/whoami/}}} request is authenticated again.
This requires a concurrent same-session request and the narrow save-window
interleaving.
==== Important Non-Claim
The simpler flow below was tested and is not sufficient:
1. /slow-save/ pauses inside the view.
2. /logout/ deletes the session.
3. /slow-save/ later finalizes.
In that ordering, cache/file/db/cached_db correctly raise
SessionInterrupted
or otherwise do not restore authentication.
==== Credit
This, including the attached test script, was reported to the Security
Team by Jaeyoung Jang (@BORAMAE). In the ticket, some edits were made to
the original report.
--
Ticket URL: <
https://code.djangoproject.com/ticket/37249>
Django <
https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.