Possible logout security problem with CVS version
| Project: | Drupal |
| Version: | 4.7.0-beta3 |
| Component: | system.module |
| Category: | bug report |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | closed |
Jump to:
I am on my home machine operating as localhost. I am using a CVS version I downloaded less than a week ago, and I have clean URLs enabled and working with no contributed modules loaded in the modules directory. If you need to know more, I posted how I enabled clean URLs, and more about my system's setup here: http://drupal.org/node/10840
I login as user 1. All is normal. I log out, all looks normal. I type in http://localhost/drupal-cvs/admin in the address box of my browser (Opera 7.51), press enter, and I am logged in without having to type my password.
I logout again and I close the drupal window in the browser. I reload Drupal in the browser. All looks normal, with the normal login screen appearing. I do not login and give my password. I type in http://localhost/drupal-cvs/admin in the address box of my browser and press enter and I am again logged in without having to type my password.
I logout, close the window and close Opera. I restart Opera. I do not login and give my password. I type in http://localhost/drupal-cvs/admin in the address box of my browser and press enter and I get the expected "Access Denied" message, INSTEAD of being logged in again without typing my password.
-----------------------------
I turn OFF Clean URLs, logout, close Opera and then restart Opera. I login as user 1, all works well and the address bars shows the expected "?=".
I logout, all looks normal.
I type in http://localhost/drupal-cvs/admin in the address box of my browser and press enter and I get the expected "Access Denied" message, INSTEAD of being logged in again without typing my password.
I type in http://localhost/drupal-cvs/?=admin in the address box of my browser and press enter and again I get the expected "Access Denied" message, INSTEAD of being logged in again without typing my password.
This is the response that I expected unlike the response when clean URLs is enabled. I don't know if this is a security problem or not but it does not appear that the logout function is correctly functioning when clean URLs is enabled
#1
Well, I think you have not pressed reload when "I type in http://localhost/drupal-cvs/admin".
RFC 2616 section 13.13:
(...) History mechanisms and caches are different. In particular history
mechanisms SHOULD NOT try to show a semantically transparent view of
the current state of a resource. Rather, a history mechanism is meant
to show exactly what the user saw at the time when the resource was
retrieved. (...)
Now, Opera just does that.
However, just for reassurance, I've checked user.module and there is a session_destroy() call in the user_logout() function, so all is well: if you log out, your session is destroyed.
#2
Hello,
I have also seen this sort of behaviour, when I login as user 1, access some content, then logout and log in as user 2 I can enter the URL that user 1 was accessing and see their content. I understand that session is being destroyed and I understand that history might be showing the old cached pages, but if I close the browser down and start it again then this problem cannot occur.
1) Due to security on a shared system and the fact that users would not reasonably be aware of this behaviour, could you force the browser to close on logout?
2) If this system was used in an on-line banking environment then it would pose a serious security risk, so they must have some way to prevent this from happening. Is it possible to code the pages so that they cannot be cached, and so every instance would be forced to retrieve a fresh copy from the server?
3) Can the session destroy cached content on logout. This is the best solution as the user does not need to worry about shutting down the browser and caching will benefit the user who is currently logged in.
If you can tell me how to modify my Drupal site to have either 1) or 2) that would be suitable for now.
Thanks.
#3
This problem could be solved by regenerating the session id every time the user level changes. Probably related too, session_write_close() ought to be called before sending a header location request.
#4
BTW, aren't this kind of things better discussed through the security resources. I mean, these issue may be giving ideas to script kiddies et al.