+- CodeIgniter Forums (https://forum.codeigniter.com)
+-- Forum: Archived Discussions (https://forum.codeigniter.com/forumdisplay.php?fid=20)
+--- Forum: Archived Development & Programming (https://forum.codeigniter.com/forumdisplay.php?fid=23)
+--- Thread: Random logout (Correction: Session library issues with session_update under async AJAX scenario). (/showthread.php?tid=43083)
Random logout (Correction: Session library issues with session_update under async AJAX scenario). - El Forum - 06-29-2011
[eluser]gdurban[/eluser]
Hi everyone, I want to ask if someone is experiencing randoms logout? You are logged in a system and suddenly you are out (using CI of course). And the problem is in the sess_update method of session class. Why is regenerating the session_id every 5 minutes? Which attack is prevented with this?
Bug already reported.
What is the solution for that?, because I am having the same problem. Prevent updating for the cookie in ajax request or disabling the session update?
Random logout (Correction: Session library issues with session_update under async AJAX scenario). - El Forum - 06-29-2011
[eluser]gdurban[/eluser]
Making more research in the forum, I found that this problem was already solve.
Solved session bug
Is this solution the best solution to this bug? Is CI going to remove this bug from the framework?
Random logout (Correction: Session library issues with session_update under async AJAX scenario). - El Forum - 06-30-2011
[eluser]gdurban[/eluser]
Hello everyone.
The use of library session is causing problems when you use asynchronous AJAX request, because the framework update the cookie, from time to time.
If you make two AJAX request that bring the same cookie, and the first one update the cookie, then the second request is invalid, and the session library remove the cookie. The next request has no valid cookie.
Is this a bug?
The solution proposed in the previous reply is the official patch for this problem?
Thanks.
Random logout (Correction: Session library issues with session_update under async AJAX scenario). - El Forum - 06-30-2011
[eluser]WanWizard[/eluser]
Afaik there are still no activities in that area, other then the suggestion to disable session ID rotation on ajax calls (search on sess_update and is_ajax to find how to do that).
Random logout (Correction: Session library issues with session_update under async AJAX scenario). - El Forum - 06-30-2011
[eluser]gdurban[/eluser]
[quote author="WanWizard" date="1309447070"]Afaik there are still no activities in that area, other then the suggestion to disable session ID rotation on ajax calls (search on sess_update and is_ajax to find how to do that).[/quote]
Thanks Wan from your reply. What about the fix you made? Is a good solution for this problem? Or is better to avoid session updates on AJAX calls?
Do you know which attack is prevented updating session_ids from time to time?
Thanks,
Guille.
Random logout (Correction: Session library issues with session_update under async AJAX scenario). - El Forum - 06-30-2011
[eluser]WanWizard[/eluser]
If you're referring to my session library, you'll have to be careful as it implements a lot of other things besides fixing the ajax issue, which might have a big impact on your application.
If this is your only issue, you'll be better off creating a MY_Session library extension, and add a sess_update() method that only calls parent:
ess_update() if the request is NOT an ajax request.Session ID rotation is one of the CI countermeasures against session hijacking.
The general idea is that if I can steal your session cookie and install that on my PC, my browser will present that to the application. If the session indicates I'm a logged in user, I am now logged in with your account. Stealing a cookie is relatively easy.
If you rotate the session ID (in CI by default every 300 seconds), you limit the time a stolen session cookie can be used. CI also includes the user's IP address and a browser identification in the session cookie, to further prevent using a stolen cookie (as you now need the same source IP address, and use the same browser agent string as well). And on top of that the session cookie is encypted, so this control information can not be altered by the thief...
Random logout (Correction: Session library issues with session_update under async AJAX scenario). - El Forum - 06-30-2011
[eluser]gdurban[/eluser]
[quote author="WanWizard" date="1309453612"]
Session ID rotation is one of the CI countermeasures against session hijacking.
The general idea is that if I can steal your session cookie and install that on my PC, my browser will present that to the application. If the session indicates I'm a logged in user, I am now logged in with your account. Stealing a cookie is relatively easy.
If you rotate the session ID (in CI by default every 300 seconds), you limit the time a stolen session cookie can be used. CI also includes the user's IP address and a browser identification in the session cookie, to further prevent using a stolen cookie (as you now need the same source IP address, and use the same browser agent string as well). And on top of that the session cookie is encypted, so this control information can not be altered by the thief...[/quote]
Thanks again Wan for your advise. My last question is:
if someone steal your cookie, that contain the IP and User Agent of the victim, then the attacker need to steal also your IP, because with the cookie only is not enough. If the attacker has your cookie and your IP, refreshing the session_id is not going to solve the problem, because the new session_id is going to end in the attacker computer. Then, I can not see the logic in this session rotation that is causing my original problem.
Do you know, or someone else known an scenario where session rotation solve a problem of cookie hijacking?
NOTE: I have 1 year working with CI and 10 as a developer. I can understand short and complex answers.
Random logout (Correction: Session library issues with session_update under async AJAX scenario). - El Forum - 06-30-2011
[eluser]WanWizard[/eluser]
It is complex (but not impossible) to steal the cookie, know what the victim's user agent string is, and spoof the victim's IP address.
If you don't rotate the session ID, the hijacker has unlimited time (= until the session expires) to set his environment up to use the stolen cookie. If you rotate the ID every 300 seconds, the hijacker only has 5 minutes in which to do that, assuming he stole the cookie directly after the last rotation. It's a matter of limiting the window of opportunity.
Is this absolutely safe: no, but it is sufficient for most websites. The effort a thief is willing to put in it is directly related to the potential profit to be gained. If you're writing an application that has such high security requirements that this is an issue, you'll in for quite a challenge.
For my own applications, I also check for proxied connections, I rotate often, I rotate whenever the security context changes, and I use a unique random token in every form, which I use for both transaction validation and CRSF protection. Secure enough for most applications.
I've got a few that need more security. There I use client-side certificate authentication (using a smartcard) for real sensitive operations, and don't store any sensitive data accessable to the frontend application. Instead, they communicate via secured webservices with a backend system that stores this data, and there are strict rules on how and what information can be retrieved and updated (no volume retrieval, need-to-know retrieval only, rate limiting on transactions, etc). Of course, then you're not talking about a $5000 site anymore...
Random logout (Correction: Session library issues with session_update under async AJAX scenario). - El Forum - 06-30-2011
[eluser]gdurban[/eluser]
Thanks Wan.
I would say that the session_id rotation cause big problems with web applications, because of concurrent AJAX request, and I do not agree that this technique is preventing a cookie hijacking attack.
Unless someone has a better explanation about what is the benefit of session rotation, I guess this issue has to be raised to the core developers of CI, because is a big problem in AJAX context. And the solution is simple, remove session rotation or do it only on demand, not by default.
Guille.
Random logout (Correction: Session library issues with session_update under async AJAX scenario). - El Forum - 06-30-2011
[eluser]WanWizard[/eluser]
I never said that session ID rotation prevents hijacking. It doesn't. It reduces the window of opportunity.
If a hacker has max. 5 minutes to use a hijacked cookie, the gain must be high enough to put the effort in. If not, they won't bother. If you don't rotate, and have a session expiration of say one year, a hacker has all the time in the world to use the cookie. Simply said, if your back garden is equiped with floodlights, buglars will go to your neighbours.
It is possible to solve the ajax issue, but it requires a rewrite of the session mechanism. How is been suggested in the past, but it hasn't been picked up. So appearently the developers don't see it as something that needs to be fixed.
Workaround is to disable rotation on ajax calls. That requires a MY_Session library, in which you overload sess_update(), and only call the parent if it isn't an ajax call. Problem solved, and you still keep all other features. Providing your application isn't a full javascript one that never does a page request, you'll still have rotation when you load a page.