Re: [RFC] [Discussion] Secure session_regenerate_id()

From: Date: Wed, 19 Mar 2014 18:33:09 +0000
Subject: Re: [RFC] [Discussion] Secure session_regenerate_id()
References: 1 2 3 4  Groups: php.internals 
Request: Send a blank email to internals+get-73305@lists.php.net to get a copy of this message
Hi Meteusz, On Wed, Mar 19, 2014 at 8:11 PM, Mateusz Kocielski <shm@digitalsun.pl>wrote: > > > login and operates as user without HTTPS, then it's not our problem. > > > > > > > Secure attribute does not matter if attacker is stripping HTTPS. > > You're right. But if user runs over transparent stripping proxy, then > managing > session by an attacker is easy (attacker replaces set-cookie from server > to victim with own value, and sends proper session on every user request). > User won't have an idea that something is wrong. Simply, running without > https > in insecure environment is asking for trouble and what you prospose won't > help > in this case. > Security measures are mitigation. HTTPS could be useless. It's the same. > I'm having hard time to explain why "detection" is better for security. > > Surveillance camera does not "prevent" crime, but "identify" who did. > > Surveillance cameras are good for security. > > I agree. But we've got more factors here, it's not a simple tool for > detection > of crimes. If we let "old session" live for x secs, what will happen to > changes done to the old session? How do you want to resolve that? We should > find a balance between complexity and security. > > Currently we have poor mitigation. My proposal provides better mitigation. > BTW, almost all security measures are "mitigation". > > Security measure does not have to "remove risk", but mitigates risk like > > HTTPS. > > Do you agree that HTTPS is security measure, right? > > Yes. > > > > > [...] > > > Problem of immediate old session deletion: > > > > > > Make session ID regeneration unreliable. (Unacceptable) > > > [...] > > > > > > I haven't found single issue in > > > bugs.php.net that session_regenerate_id(TRUE) is a problem to any > user. > > > > > > > Of course, there aren't. session_regenerate_id(FALSE) is the default now > and > > random logout by race condition is hard to be noticed by developers. > > You might be right, I just found [1]. Note the shadowhand's post: > > [...] > I think developers should be aware of the fact that HTTP is a stateless > protocol and work around that fact, not try to "fix" it with hacks that > will, > with all due respect, end up causing more issues than they solve. > [...] > I agree with his/her opinion. HTTP is stateless and we cannot force client to synchronize session ID. I'm proposing better/stricter work around than now. http://forum.kohanaframework.org/discussion/1870/race-conditions-in-session-handling/p1 Thank you for the link. Regards. -- Yasuo Ohgaki yohgaki@ohgaki.net

« previous php.internals (#73305) next »