Opened 3 weeks ago
Last modified 12 days ago
#37423 assigned Bug
File-based sessions remain accessible after integer expiry
| Reported by: | Sarah Boyce | Owned by: | Sarah Boyce |
|---|---|---|---|
| Component: | contrib.sessions | Version: | 6.1 |
| Severity: | Normal | Keywords: | not-security |
| Cc: | Patel Namraa, Chris Griffin | Triage Stage: | Accepted |
| Has patch: | yes | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
The file-based session backend does not enforce the server-side expiry time when SessionBase.set_expiry() is called with a positive integer.
A session can still be loaded using its session ID after the configured timeout has elapsed. clearsessions also leaves the expired file in place.
For example, with the file-based backend:
from django.contrib.sessions.backends.file import SessionStore import time session = SessionStore() session["foo"] = "bar" session.set_expiry(1) session.save() session_key = session.session_key time.sleep(2) SessionStore(session_key).get("foo") # Returns "bar"; expected None.
set_expiry(1) stores the integer 1 in _session_expiry. The file backend passes that value to get_expiry_age(), which returns 1 without comparing it with the file’s last modification time. The session therefore remains accessible server-side.
The backend should calculate the expiry date using the stored timeout and the file’s last modification time.
This had been reported to the security team by Chris Griffin. The security team has agreed to treat this a security hardening in public.
I recommend that we backport to 5.2.
This was then later reported publicly by Patel Namraa, who is now in cc.
Change History (7)
comment:1 by , 3 weeks ago
| Has patch: | set |
|---|
comment:2 by , 3 weeks ago
| Keywords: | not-security added |
|---|
comment:3 by , 3 weeks ago
comment:4 by , 3 weeks ago
Hi Patel, I deleted that ticket because it had already been reported to us as a possible security issue and we had not concluded our analysis.
Now that we have, I have recreated a ticket and put yourself in cc to be aware of the ticket (I also had mentioned this in the ticket description at the bottom)
comment:5 by , 2 weeks ago
| Triage Stage: | Unreviewed → Accepted |
|---|
comment:6 by , 13 days ago
| Patch needs improvement: | set |
|---|---|
| Severity: | Release blocker → Normal |
| Version: | 5.2 → 6.1 |
Will not treat as a release blocker
comment:7 by , 12 days ago
| Patch needs improvement: | unset |
|---|
This issue appears to be a duplicate of my ticket #37421, which I reported earlier: https://code.djangoproject.com/ticket/37421
However, when I try to open my ticket, Trac displays the error “Invalid ticket number — Ticket 37421 does not exist,” even though the ticket was created under my name.
Could a maintainer please check what happened to ticket #37421 and clarify whether this ticket should be marked as a duplicate of it?
Thank you.