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 [email protected] to get a copy of this message
Hi Meteusz,

On Wed, Mar 19, 2014 at 8:11 PM, Mateusz Kocielski <[email protected]>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
[email protected]


Thread (23 messages)

« previous php.internals (#73305) next »