Hi Mateusz,
On Sun, Mar 16, 2014 at 5:53 PM, Mateusz Kocielski <[email protected]>wrote:
> On Sat, Mar 15, 2014 at 08:46:29AM +0900, Yasuo Ohgaki wrote:
>
> > Application means client side application?
> >
> > Suppose you have gallery application that only shows user's photo. Every
> > request
> > for photo should use authenticated session. If
> session_regenerate_id(TRUE)
> > is called
> > during page rendering, what happens?
>
> By application I meant client side application. I don't believe that
> periodically regenerating session introduces better security. Regarding the
>
Stealing session ID is easy even with HTTPS. Therefore, changing session ID
is
the security best practice to mitigate risk.
> case you provide, if session_regenerate_id(TRUE) is used in the page which
> contains photos, then all requests for images will contain new session
> cookie. (If browser requests for photos, then body of the document was
> received, thus also headers with new cookie was received). If
> session_regenerate_id() is used elsewhere, then I think that it's not our
> problem.
It's session manager problem. Currently, session module allows to exploit
stolen session
as long as app allows even when user follows security best practice. i.e.
call session_regenerate_id()
periodically. I think almost all apps do not have proper mitigation.
There must be mitigation and it could be done with deletion time stamp by
session manager.
It's a session manager design issue. Session manager should provide
mitigation rather than leaving
it to users. IMO.
I copied following lines from previous my mail just in case you missed it.
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.
}
> However, we should update our documentation to note the problem.
>
> BTW,
>
> https://bugs.php.net/search.php?cmd=display&search_for=session_regenerate_id
> - it seems that users also don't see this issue as a problem.
>
Two of them are mine ;)
>
> > Of course attacker may, but
> >
> > 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.
> >
> > This is much better than current. Risk is mitigated rather than left
> open.
> > BTW, almost all security measures are mitigation.
> >
>
> I don't see how risk is mitigated in that case. User will lose session (if
> it
> was regenerated by attacker) which probably result in logout, I don't
> believe
> that typical user will be alarmed.
Session manager can raise error for invalid access. Programmer may catch
the
error and warn user/attacker if users are cautious.
> As a result we'll get an attacker and user
> using distinct sessions - how many applications already deny using two
> distinct sessions for one account?
This one is user (PHP developer) issue since session manager does not know
about users. Web apps may allow or disallow multiple sessions. It's
developer's choice.
Regards,
--
Yasuo Ohgaki
[email protected]