Weird Problem of unnatural logout on menu button or form button double click

[ajoo]

Hi all !

 

I am facing this very weird problem of unexpected and unnatural log out when I double click either the menu buttons or the form buttons.

 

I am using a jquery slider login panel to login users but i have been plagued with this problem where they are logged out as mentioned. I have been struggling to find the cause of for almost a week now without success. This behavior can be seen at my website whose link is

 

www.bestbet.bugs3.com/club/demo.php. The user id and password is "Itsme " & bcf134. I would be grateful if any of the gurus can take a look at it and help me solve this one. I would be willing to share the files with anyone who is willing to take a look at them.

 

Looking forward to responses from all of you,

 

Thanks tons.

 

 

 

 

[justsomeguy]

That's related to the session cookies. If you look at the network requests using Firebug or another developer tool, look at the cookies being sent and received. The session ID cookie changes every time. On some requests the server tries to set 3 different session IDs in the same response. I'm not sure why it would do that, but the double-clicking problem is because the first request tries to set a new cookie but gets aborted, and then the second request is using the wrong session ID. The root cause for that is because the session ID changes for every request. I'm not sure if that's supposed to be a security feature or what, but there are other ways to secure sessions.

[ajoo]

Hi justsomeguy, Thanks loads for that insight. I will now look along those lines and maybe i'll be able to locate the problem.

 

I'ld like to mention though that in almost all the tutorials that I looked up on the net, they have one of the first line in the php page that says "session_start" followed by session_regenerate_id(). And this is on all the pages that are linked to the main page. So if a user visits one of the links on a page, the first few top lines of that page would have the "session _start" and "session_regenerate_id".

 

So every time the page runs through itself or is refreshed the session_id is going to change. I also read somewhere that every time the program goes through an important part of the program ( for example a user logs in ) the session_id should be changed for security reasons.

 

I wanted to design a login page where if a user is already logged in at a given place and wishes to login from another, the system invalidates the previous session and lets him login from another place. Keeping all this in mind I designed a page which has a session_secure() at the very top and is traversed every time it is refreshed and it also checks if the user is not already logged in which case it invalidates the previous session and validates a new one.for the same user.

 

So session_secure runs once in a page except when a user is logging in. In that case session _secure is called once again in the login routine once the user has been identified and the session is then given a new session_id.

 

I have one more question and that is I am using "include members.php" to display the member page and its not via a link. So at the end of the main login file I have this include command which is executed if a valid user is logged in and displays the user page. Will I have to have the session_secure() routine which houses the session_start() and regenerate_id() routines on the members.php page and all the other sub pages that member.php calls for maintaining a secure session OR does the include command considers the pages (members.php) that it loads as an extension of the main page and so there is no need to add session_secure on these and sub pages.

 

I'll look into the session again and try and see what i can find. I'll come back again on this later.

 

Thanks loads some_nice_guy !

Edited February 13, 2014 by ajoo

[davej]

I have also read such things but I don't know how well that really works. I remember that ASP.NET does something like that. With mobile devices and WiFi I don't know if that is such a good idea unless there is a good solid handshaking scheme in place, and I remember thinking to myself that it might be better to layer another scheme on top of the session if you want to prevent session theft.

Edited February 13, 2014 by davej

[justsomeguy]

Regenerating the session ID on every request is one extreme of trying to keep sessions from being hijacked (although it is certainly not bulletproof at doing so). The side effect of always regenerating the session ID is exactly what you're seeing - if the browser sends a request to the server but then cancels the request before it receives a response, then the session is history.

 

If you want to protect against session hijacking, the best way is to use SSL on your site. You can add additional measures such as storing the IP address and user agent string with the session and checking those on each request. If they don't match then close the session. There is quite a bit of discussion online about preventing session hijacking though.

 

 

 

I wanted to design a login page where if a user is already logged in at a given place and wishes to login from another, the system invalidates the previous session and lets him login from another place.

One way to do that is to store a login token in both the database and the session. When they log in you generate a login token and save it in the database, and also in the session. On every page load you compare the session token with the database token. If they are different then the account has logged in again and you can kill the session.

 

For included files, think of it as copying and pasting code. The included code runs in the same context as the include statement, exactly as if the code was copied and pasted (minus a few changes with various constants and things like that, e.g. the __FILE__ constant always points to the file currently being executed, while $_SERVER['SCRIPT_NAME'] points to the original file that was first loaded).

[davej]

I don't really see how regenerating the session cookie on each page load is going to provide security, but it would cause unexpected log-outs if session-stealing was attempted. The thief would respond first and grab the session and the legitimate user would find themselves mysteriously logged out.

[justsomeguy]

It would provide security in the sense that a captured session ID couldn't be used if the user had already clicked another link.

[davej]

Yes, but since a session ID is going to be captured within a fraction of a second I don't see much advantage if the thief has to respond within a few seconds rather than a few minutes. The thief can easily respond within a fraction of a second. A better scheme would be a pseudo-random sequence that is sent in addition to the session ID. Unless the thief can duplicate the random sequence the theft would be detected. The seed for the random generator could be the user's password so it would never be transmitted (only the hash of the password would be transmitted).

[Hadien]

Though not exactly what you guys are talking about, I was reminded of this video that posed some relevance to this subject that I think you may enjoy seeing. Cross Site Request Forgery - Computerphile

[davej]

I'm rather envious of that guy's British accent. Strange that he doesn't seem to have a video on session hijacking.

 

I was also thinking that the server could supply a page count and the client would reply with the mystery value associated with that count. In other words the random mystery value would actually be a hash of a known but secret value (such as date plus user password) salted with a count. The server could also monitor the browser signature and ip -- but that is old-school.

Edited February 14, 2014 by davej

[ajoo]

Hi Gurus !

 

 

 

Regenerating the session ID on every request is one extreme of trying to keep sessions from being hijacked (although it is certainly not bulletproof at doing so). The side effect of always regenerating the session ID is exactly what you're seeing - if the browser sends a request to the server but then cancels the request before it receives a response, then the session is history. ----- Justsomeguy

Just as Justsomeguy mentioned, It is indeed the session_regenerate_id() function that is causing the logout problems on my website.

 

Would it mean that all websites that use session_regenerate_id() would log out the user if say he/she pressed and kept pressed the F5 key ( refresh ) on the keyboard?? Other than multi-clicking the same button, my website logs me out if i keep pressed the refresh button for just a little while.

 

If not so, then does it mean that there is a way in which we can use the session_regenerate_id() and take care of this problem of getting logged out on multiple refreshes or double, tripple clicking a button.

 

 

 

A better scheme would be a pseudo-random sequence that is sent in addition to the session ID. Unless the thief can duplicate the random sequence the theft would be detected. ----Davej

 

1. I would be grateful if you can demonstrate that via an example. I am unable to understand that how, once my session has been hijacked , would then it matter at all about the pseudo-random key? I mean after all the session_id is also a sort of random key itself. I would be glad if you can explain that in greater detail and with an example of its implementation.

 

Thanks !

Edited February 22, 2014 by ajoo

[justsomeguy]

Would it mean that all websites that use session_regenerate_id() would log out the user if say he/she pressed and kept pressed the F5 key ( refresh ) on the keyboard??

It means that if you ever send a request to the server, and then cancel the request, your session is lost. If you click a link and hit stop before the page loads, your session is lost. Refreshing over and over probably causes at least one request to go out that ends up getting canceled. At that point the server is using a different session ID than the client, since the client never got the response from the server.

If not so, then does it mean that there is a way in which we can use the session_regenerate_id() and take care of this problem of getting logged out on multiple refreshes or double, tripple clicking a button.

No, if you regenerate the session ID on every request then that's the side effect you have to live with. If you want to prevent session hijacking then you should do some research to figure out what people are doing and what they're saying. There are a few posts here: http://stackoverflow.com/questions/22880/what-is-the-best-way-to-prevent-session-hijackinghttp://stackoverflow.com/questions/12233406/preventing-session-hijacking

[davej]

My concept is simple. You would obtain a Javascript library containing a hash function that your server-side language also has available to it. You then use an SSL protected login sequence. After the login many websites exit SSL for efficiency, but during SSL there was opportunity for the client and server to agree on a random secret key. Each time the client makes a request it can now supply a salt, perhaps a count, and the hash of (salt+secret) and the server can quickly test this to see if it is valid. Alternately the server could supply a challenge value and the client would hash it and return it. There is no re-synchronization problem because the salt and hash are provided with each client request. A hijacker can steal the session ID but cannot generate a valid fresh hash. The same secret could be used to salt a hash of the body of the message so that any change to the message could be detected. If SSL is not used for the login phase then you are much, much more vulnerable.

Edited February 24, 2014 by davej

[justsomeguy]

If you're using SSL then the problem is basically solved, just use SSL and require secure cookies.

but during SSL there was opportunity for the client and server to agree on a random secret key.

How does the browser save that in a way that it can't be stolen?

Each time the client makes a request it can now supply a salt, perhaps a count, and the hash of (salt+secret) and the server can quickly test this to see if it is valid.

What would stop someone from submitting the same salt and hash and having the server approve that? A salt and hash is just as good as a session ID, it provides the same level of security.

Alternately the server could supply a challenge value and the client would hash it and return it.

Wouldn't that add another request into the mix? The client sends a request for a page, the server responds with a challenge, the client sends a second request, and the server delivers the file?

[davej]

> If you're using SSL then the problem is basically solved, just use SSL and require secure cookies.

 

Yes, but even on Amazon and Ebay you are not kept in an SSL session.

 

> How does the browser save that in a way that it can't be stolen?

It is true that I'm just talking out of my ### regarding SSL because I have not tested this concept. In my non-SSL application I would just put it in a global since the requests are going to be Ajax and the page won't be reloading (and the secret would be the unhashed password), but to have SSL and then drop out of SSL you might have a page-load that would wipe your globals. HTML5 local storage might be a solution. > What would stop someone from submitting the same salt and hash and having the server approve that? A salt

> and hash is just as good as a session ID, it provides the same level of security.

Single use. You either salt the secret with an ever increasing count which the server verifies has not been used, or the server provides a challenge salt which is returned with the corresponding hash of (secret+challenge). Again it's up to the server to assure that the challenge salt has not been reused. > Wouldn't that add another request into the mix? The client sends a request for a page, the server responds with a challenge,

> the client sends a second request, and the server delivers the file?

 

It might if an attempted attack was in progress or there was a transmission problem. Otherwise I think it would be pipe-lined. Each client request would simply answer the previous challenge.

 

I'm sure it can't protect you from an all-knowing-blocking-man-in-the-middle because that situation is just about impossible, but it might protect you from script-kiddies at the coffeeshop. As I say though, the effect of dropping out of SSL might be a problem.

Edited February 25, 2014 by davej

[justsomeguy]

Yes, but even on Amazon and Ebay you are not kept in an SSL session.

OK. Sounds like they're vulnerable, then. That is not a reason to not require SSL.

In my non-SSL application I would just put it in a global since the requests are going to be Ajax and the page won't be reloading

If you're talking about a special-purpose application or specific browser requirements, then yes you can design the application with session hijacking in mind. For general-purpose usage that isn't going to work, though.If you want to develop a proof-of-concept then go ahead though. If it stands up to peer review then people will thank you for it.

[davej]

If "helpful people" in the "security community" didn't feel the need to generate and promote easy-to-use tools...

 

http://www.youtube.com/watch?v=ZtZPR-TAEZw

[justsomeguy]

Security by obscurity is not security. It doesn't matter how easy it is to snoop on traffic, if that traffic was encrypted then it wouldn't matter.

[davej]

But are you up against "Dr. Darknet" or just some dumb, bored 15yo kid?

[justsomeguy]

I guess that depends how much you value your customers and their data. Ask Mt. Gox what they think about security lately, and if "a little" security is "enough". Their problem wasn't session hijacking, but security is sort of an all-or-nothing concept. Sort of like pregnancy. You can't be a little bit pregnant. If your site is a little bit secure, then it's not secure.

[davej]

Well, my whole concept as described earlier seems to be totally bogus. It seems that http local storage and https local storage are kept isolated, so even though appropriate keys can be securely stored during an SSL log-in connection you can't access those keys later if you change to a non-SSL connection.