I have a sample site I am working up, and as part of it I have made a login / user management system. Its sessions based, though I use cookies to hold an encrypted user hash which will allow them to log in automatically when they come back should they choose to. The cookie also functions as an automatic relogger if the IP of the session holder should change. I hope that this will make it harder to hijack the session, but only if you haven't already aquired the cookie I guess.
My problem is that when the user logs in they enter their username and password into a set of textboxes and presses submit, the details are evaluated and then authorization is either granted or denied. The user goes along using the site, then they log out. This is all fine as far as I can tell.
But then, if the next user were to come along and hit 'back' until they reached the page after the sign in form, the values still exist and the user is re-validated and accepted.
I guess I am wondering if there is an easy solution to this, or even if I need worry about it. Short of, say, numbering login requests and storing that value in the database to make sure each login is unique, I dont know what to do.
Actually, that is quite do-able now that I come to say it. Is this a good idea? Is there an easier way?
Thanks.
'Back'-ing into secure mode after log out
Moderator: General Moderators
Remove the session cookie when a user logs out then check for the cookie on every page load. Also, set pragma:no-cache in the headers.
If the user logs out and then hits the back button, the browser *should* reload the page, see that the cookie isn't there, and then throw an error of your choosing. If the page does get cached for some reason, it'll look as if they are logged in, but it'll throw an error as soon as they click on something.
~Scott
If the user logs out and then hits the back button, the browser *should* reload the page, see that the cookie isn't there, and then throw an error of your choosing. If the page does get cached for some reason, it'll look as if they are logged in, but it'll throw an error as soon as they click on something.
~Scott
Re: 'Back'-ing into secure mode after log out
> Its sessions based, though I use cookies to hold an encrypted user hash
> which will allow them to log in automatically when they come back
> should they choose to.
If you're interested in reading a suggested technique for this, try this:
http://fishbowl.pastiche.org/2004/01/19 ... t_practice
> I hope that this will make it harder to hijack the session, but only if you
> haven't already aquired the cookie I guess.
There are practices that can help prevent session hijacking, even if the session identifier is compromised:
http://shiflett.org/articles/the-truth-about-sessions
http://phpsec.org/projects/guide/4.html#4.2
> But then, if the next user were to come along and hit 'back' until they
> reached the page after the sign in form, the values still exist and the
> user is re-validated and accepted.
You can hide the POST request from the browser's history mechanism:
http://shiflett.org/articles/guru-speak-nov2004
> which will allow them to log in automatically when they come back
> should they choose to.
If you're interested in reading a suggested technique for this, try this:
http://fishbowl.pastiche.org/2004/01/19 ... t_practice
> I hope that this will make it harder to hijack the session, but only if you
> haven't already aquired the cookie I guess.
There are practices that can help prevent session hijacking, even if the session identifier is compromised:
http://shiflett.org/articles/the-truth-about-sessions
http://phpsec.org/projects/guide/4.html#4.2
> But then, if the next user were to come along and hit 'back' until they
> reached the page after the sign in form, the values still exist and the
> user is re-validated and accepted.
You can hide the POST request from the browser's history mechanism:
http://shiflett.org/articles/guru-speak-nov2004