-3

I want to know how some applications log out users if user refreshes the page manually or click on back button other than clicking on provided menus. I have seen this scenario in many banking applications in India. After thinking, one solution that comes to my mind is for each logged in user i can store current session id and a next session id and pass session id in url. So now if user refreshes the page and if session id is other than the next session id then we can simply log them out. So what i can do is, if the next session id is found in the url then i can set current session id manually.

But this can be hectic from a programming point of view as i will have to set the next session id in each url for the rendered page and i am worried if it is a security threat?

Any thought on this?

Rakesh Kumar
  • 157
  • 1
  • 13
  • 1
    Dont put session_ids in URLs. This can lead to session hijacking – DarkBee Jul 31 '14 at 09:03
  • @DarkBee It's not so much that it leads to session hijacking(storing session ids in cookies has the same risk in that) but more that it can lead to someone sharing a link to a specific page and accidentally sharing their session id through that. – teuneboon Jul 31 '14 at 09:07

1 Answers1

0

Basically yes, that's about what you'd do. For security purposes you should never transport the session id in the URL, leave that in a cookie. However, you can save a random token in the user's session:

$_SESSION['token'] = uniqid(null, true); // quick prototype, not the best method

Then you embed this token in every single URL on the page:

<a href="someMenuItem.php?token=<?php echo $_SESSION['token']; ?>">

Then on each page load, you check whether the tokens are identical. If they are, you generate a new random token; otherwise you destroy the user's session.

Having said all this...

THIS IS A TERRIBLE IDEA!!!

It's extremely user unfriendly. Refreshing pages or moving back is a normal interaction paradigm on the web. Sometimes it's a necessary thing to do, e.g. if the network connection was bad and only half the page loaded, you'll need to reload it. You're actively making your page unusable if you implement such restrictions. Any security benefits this may provide can largely be obtained in other ways, there's no need to do this. See PHP Session Fixation / Hijacking.

Community
  • 1
  • 1
deceze
  • 510,633
  • 85
  • 743
  • 889
  • Yes that sounds good.. Rather than storing id, i can assign something like token and then match it. As far as need is concerned, i have stated in my question that i have seen it in many application so i thought i should discuss it. Also i think, rather than storing token in session and match every time, we should store it in database because session values can always be read so will need extra overhead. – Rakesh Kumar Jul 31 '14 at 09:46
  • Your last remark about sessions vs. database doesn't make any sense whatsoever. – deceze Jul 31 '14 at 09:47