I have investigated this issue and the session is not recovered with this attack. Django uses a caching framework that allows template content to be generated and cached. When this occurs, the cache entries are written that may potentially contain sensitive data, but these cache entries are associated with the session identifier. Unfortunately these cache entries may not be invalidated/cleared when the session is destroyed. Repeating the steps in the initial report results in a view that is comprised of the normal, unauthenticated view, with the exception of the welcome banner and some profile related menu items. When any of these menu items is selected, the user is forced to authenticate (expected, since they are simply viewing a cached template). The root cause of the bug seems to be in the cache.py; this function implements the delete method required by base.py, but the base.flush() method does not pass the sessionid when delete() is called. As a result the cache.delete() call does not actually delete anything. The flush method is ultimately called by auth.logout, which is in turn called by AMO to log out a user.  django/contrib/sessions/backends/cache.py  django/contrib/sessions/backends/base.py  django/contrib/auth/__init__.py
Has this been reported to the django devs?
Not yet, some additional research by someone who understands how more about how django caching works and knows python better than me should probably take a look before it is reported. If you or another dev can confirm my conclusions in comment 1, I will report it to Django.
We use the database backend for sessions, so sessions.backends.cache is nowhere in our code path. Template caching is handled through cache-machine completely separately, but no templates are cached for authenticated users. I'll look at what happens when we call logout.
I have recorded steps to reproduce this issue, today it didn't worked as described in primary report - step 7 has changed: I clicked on ADD-ONS link twice instead of page refresh.
We have been able to repro this issue. I don't know why we weren't able to before.
Status: UNCONFIRMED → NEW
Ever confirmed: true
The root cause of this bug appears to be the integration between the cake and django session management. The changes to remove cake also remove this issue.
Whiteboard: [infrasec:cookie][ws:normal] → [infrasec:cookie][ws:critical]
Whiteboard: [infrasec:cookie][ws:critical] → [infrasec:cookie][ws:high]
what is the status of this bug?
if comment 9 is correct it'll be resolved as soon as PHP is gone. This Thursday all traffic to PHP is being turned off and then $some_amount_of_time later, once we're satisfied all is well, we can remove it from the servers altogether.
This is fixed now that PHP is gone. I verified by watching the sessions table in the database.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Keywords: wsec-authentication, wsec-session
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.