Re: Solution for session_regenerate_id() issues
Hi,
>> How do you detect attacks by delaying deletion? And what do you do if
>> you detect an attack to protect yourself from it? If it has to allow
>> valid requests, it will also allow attackers because session ID is the
>> only thing that you're looking for.
>
>
> It was written in previous mail in this thread.
>
> Users may set timeout flag in $_SESSION array and check the value if session
> could be active or not. In order to do that in user land, one may do
>
> session_start()
> // ** check timeout flag **
> if (!empty($_SESSION['VALID_UNTIL']) && $_SESSION['VALID_UNTIL']
> < time()) {
> session_destroy();
> trigger_error('Possible session hijack attack detected');
> die('Possible session hijack attack detected');
> }
>
> // ** set timeout flag **
> if ($_SESSION['LAST_REGENERATE'] < time() + 600) {
> $_SESSION['VALID_UNTIL'] = time() + 60; // Shorter is better, but rather
> large value is set for lost radio/hand over/etc. Old session is allowed to
> use as valid session for 60 seconds.
> session_commit(); // Need to save above data in old session.
> session_start();
> $_SESSION['LAST_REGENERATE'] = time(); // Update regenerate time here.
> session_regenerate_id(); // New session ID and old session data with old
> session ID is left
> unset($_SESSION['VALID_UNTIL']; // This session should not be deleted
> later.
> }
>
> Above example is allowing 60 seconds window for legitimate user and
> attacker. If session is hijacked,
> - User could know attack if session ID is regenerated by attacker.
> - Attacker could know there is hijack protection if session ID is
> regenerated by user.
>
> LAST_REGENERATE is better to be NEXT_REGENERATE with 'lazy_write' to
> prevent unneeded session writes as I wrote in different mail in this thread.
>
> Exception is easier to handle error. I would like to implemented it with
> exception.
I don't get it ... I thought you were proposing a solution in PHP
itself, not userland code. Am I missing something?
>> > Immediate deletion is worse than delayed deletion.
>>
>> I don't agree with this, but I guess we'll have to agree to disagree on
>> it.
>
>
> Letting user and/or attacker to know there is protection against session
> hijack
> is good for better security. It wouldn't prevent attack, but it mitigates
> risk.
> It's the same as having surveillance camera for security.
Surveillance cameras may scare off a random criminal in real life, but
this is because it would film them and they'd be easily identified.
We're on the internet here and everybody can hide themselves, alerts
don't scare the kiddies.
- Letting the _application developer_ about an alleged attack is good.
- Letting the user (as in an end user, just somebody using the site)
know about is irrelevant to security and bad from a usability point of
view, nobody likes to see errors in websites, to say the least.
- Letting the attacker know about it is not just not good, it's
really bad. It further exposes details about the application to the
attacker; details that can be used to aid them in a more sophisticated
attack. They now know that there's something stopping them at some
point and so they learn how to avoid it.
The first can also be implemented in userland with something like this:
$_SESSION['last_regenerate'] = time();
session_regenerate_id(FALSE);
// Later, detection:
if (isset($_SESSION['last_regenerate']) &&
$_SESSION['last_regenerate'] > time() + 60)
{
session_destroy();
// send email to webmaster
}
> I'm proposing session manager does its task to make session management
> as secure as possible. I may agree with you if could explain why immediate
> deletion is better than delayed.
It's simple - immediate deletion doesn't leave a time window for
attackers to exploit.
But speaking of sessions and security, I'll mail you privately about
something because I didn't see an option in the bug reporting form to
mark it as a private one.
Cheers,
Andrey.
Thread (24 messages)