Hi Stas, On Wed, Jan 13, 2016 at 10:08 AM, Stanislav Malyshev <smalys...@gmail.com> wrote: >> 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.
Yes. The patch treats empty session ID cookie as no session ID cookie. > >> 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? You should be able to see $_SESSION[v++] reset by empty session ID cookie. It's been a while so it may be fixed in chrome/firefox, though. Browser should read/write cookie values by atomic manner, but RFC does not require to do it, AFAIK. I suppose we cannot rely on browser implementation. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
