#31412 closed Bug (wontfix)
Database timing attack against sessions.
| Reported by: | Brian May | Owned by: | |
|---|---|---|---|
| Component: | contrib.sessions | Version: | 3.0 |
| Severity: | Normal | Keywords: | |
| Cc: | Simon Charette, Florian Apolloner, Paul McMillan | Triage Stage: | Unreviewed |
| Has patch: | no | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
CVE-2019-16782 was assigned to Ruby Rack. Basically, an attacker, can conduct a timing attack by sending specially crafted session ids and timing how long it takes for the database to lookup the session. From this the attacker can guess valid session ids.
To me it looks like Django, by default, stores sessions on the database (using django.contrib.sessions.backends.db) in a very similar manner. Does this also mean it is vulnerable to the same timing attack?
Change History (10)
comment:1 by , 5 years ago
follow-up: 3 comment:2 by , 5 years ago
Looking at Rack patch I think this might have a bit of overlap with #21076 (PR). If session ID were hashed it wouldn't be possible to use timing attacks on the btree-index to statistically walk your way to a valid session ID. It might be time to revive that old PR.
comment:3 by , 5 years ago
Replying to Simon Charette:
Looking at Rack patch I think this might have a bit of overlap with #21076 (PR). If session ID were hashed it wouldn't be possible to use timing attacks on the btree-index to statistically walk your way to a valid session ID. It might be time to revive that old PR.
Agreed.
The Rack solution become complicated because (a) they wanted to preserve existing sessions and (b) for reasons I don't understand they decided to split the session id into a "public" session id and a "private" session id where the names "public" (meaning non-hashed id) and "private" (meaning hashed id) don't mean what you might expect (they both need to remain secret).
comment:4 by , 5 years ago
| Cc: | added |
|---|
comment:5 by , 5 years ago
| Cc: | added |
|---|---|
| Summary: | database timing attack against sessions → Database timing attack against sessions. |
comment:6 by , 5 years ago
| Owner: | changed from to |
|---|---|
| Status: | new → assigned |
comment:7 by , 5 years ago
| Owner: | removed |
|---|---|
| Status: | assigned → new |
comment:8 by , 5 years ago
| Resolution: | → wontfix |
|---|---|
| Status: | new → closed |
Thank you for the report.
After consideration, the Django Security Team conclude that this is not a practical attack vector.
Work on the related hardenings, such as the referenced tickets should continue.
comment:9 by , 4 years ago
Carlton, could you please share Django Security Team reasoning about the impractically of session timing attack?
This page shows up if you google for general session storage implementation advice (not specific to Django). It would be nice to learn the details, if you can share them.
comment:10 by , 4 years ago
Alexey, what was missing was a demonstration of how this might be exploited. Yes, work on the related tickets but this wasn't something we need to pick up as a security issue.
If that is not correct, a proof-of-concept sent privately to security@… as per the Reporting security issues guidance is appreciated.
The security issue referenced here is already public, I don't see any issues with making this bug report public also. Apologies if I got this wrong.