Re: Fixing bug #68063
| From: | Stanislav Malyshev | Date: | Wed, 13 Jan 2016 01:08:43 +0000 |
| Subject: | Re: Fixing bug #68063 | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-90586@lists.php.net to get a copy of this message | ||
Hi!
> The root cause is browser's cookie handling.
> It appears that browsers do not lock cookie while updating cookies.
> Therefore race condition happens and browsers send empty cookie
> sometimes. I haven't checked the code, but observed it happens.
>
> I observed handful empty cookies a day with web site has millions
> accesses per day. I circumvented this issue with method described
> in https://wiki.php.net/rfc/precise_session_management
> It worked perfectly.
OK, leaving aside open RFCs, I think we should treat empty ID cookie as
if no cookie were provided at all. Looks like that is what the patch
does? If true, we should merge it. I can do it later tonight.
> Accepting empty cookie is security issue because multiple users
> get the same session ID on occasion. Previous fix that disallows
> empty cookie/raising error works partially, but it was inappropriate
> fix. PHP shouldn't raise error for empty cookie, but should try to
> set new session ID.
Since it is a browser bug and not a PHP bug, I'm not sure whether that
really qualifies... But I guess it woudn't hurt to fix that.
> I found simple way to observe lost sessions. Please refer to
> https://bugs.php.net/bug.php?id=69127
> It appears that even single threaded CLI server can cause race.
That may be some race condition, but that does not demonstrate empty
session ID as I understand?
--
Stas Malyshev
smalyshev@gmail.com