Re: [RFC] [Discussion] Secure session_regenerate_id()
> > [...]
> > Errors may be raised for either legitimate user or attacker. If error is
> > raised for legitimate user, legitimate user could know they are under
> > attack.
> > (Possibly network is dangerous or app has vulnerability) If error is raised
> > for attacker, attacker could know they might be caught by illegal access.
> > [...]
> >
> > I wonder how many legitimate users will realize they're under attack. For
> > average user it will look like application does weird things (i.e. logout
> > immediately). If network is dangerous or app has vulnerability then we
> > cannot
> > fix the problem - you can't make n-th layer secure if (n-1)-th layer is
> > insecure.
> >
>
> It depends on how developer treats possible attack. Session manager raises
> exception only. Developer may ignore or give detailed information about the
> risk in their page.
>
> My proposal does not alert victims/attackers automatically, but only give
> tools for developers.
> How to use tools is up to developers.
>
>
> [...]
> > Stealing session ID is easy regardless of HTTPS. Attacker can set up fake
> > router by ARP spoofing. Most networks do not have ARP spoofing prevention,
> > even detection. For HTTP, attacker can view session ID simply. For HTTPS,
> > attacker can set up transparent HTTPS stripping proxy and steal session ID.
> > Most users do not care much if they are connecting via HTTPS or not.
> > [...]
> >
> > What if application uses secure attribute on session cookie? We've got
> > already
> > session.cookie_secure setting which seems to solve the issue. I don't see
> > how
> > by introducing your proposal will make situation better. If application
> > allows
> > 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.
> 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.
> 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.
[...]
Thanks for your answers.
[1] -
http://forum.kohanaframework.org/discussion/1870/race-conditions-in-session-handling/p1
Kind Reagards,
Mateusz Kocielski
Thread (23 messages)