Hi Andrey,
On Mon, Mar 17, 2014 at 8:00 PM, Andrey Andreev <[email protected]> wrote:
> I don't think delaying deletion is a good idea, it just brings more
> complexity to the whole process and I can't really imagine how it
> would be handled, since PHP is not run as a daemon - this is the
> reason why the session GC is triggered by chance instead of running as
> some type of a cron job.
>
> Applications usually handle this by not regenerating session ID during
> an ajax request. Most JS frameworks would send a 'X-Requested-With:
> XMLHttpRequest' header to provide a way for Ajax detection, and PHP
> frameworks have helper methods to look for that header. Even if they
> don't - anybody can implement a similar solution for their own
> application.
>
> With that said, I'd rather give a +1 for changing the
> session_regenerate_id() default action from "don't delete" to
> "delete", like you've previously suggested.
>
> Btw, I wouldn't worry about stolen session IDs ... if somebody steals
> it once, they'll do it after regeneration as well. Session ID
> regeneration is only effective against brute-force attacks.
>
Do you realize that stolen session could be used by attackers without
any indication currently? Unlike read_only, this is not about legitimate
user's
request. It's very easy to set up fake router by ARP spoofing. Stripping
HTTPS
is simple task and almost all users don't care about if HTTPS is used or
not.
Script kiddy is enough to steal session ID.
To mitigate regeneration risk and keep session availability at the same
time,
delayed deletion is mandatory. It's also better than immediate deletion
because
it allows to detect possible attack. As you mentioned, if session ID could
be
stolen, session ID may be stolen as many times as attacker wants.
Keeping session ID secure as much as possible is session manager's task.
Current mitigation that relies on GC is far from optimal and not acceptable.
Immediate deletion is worse than delayed deletion.
Regards,
--
Yasuo Ohgaki
[email protected]