Hi Stas, On Wed, Jan 13, 2016 at 8:03 AM, Stanislav Malyshev <smalys...@gmail.com> wrote: >> I've disallowed empty session ID, but it wasn't a >> appropriate fix. >> >> https://bugs.php.net/bug.php?id=68063 > > Could you explain a bit more about the part where there are empty IDs > generated? You say it "is browser's cookie handling" - could you explain > more about it?
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. > >> I made appropriate patch for this issue. It should be >> applied from PHP 5.5 to master. I attached patch to >> the bug report. Could you apply it from PHP 5.5? Or >> shall I commit it from 5.6? then cherry pick? > > Is that a security issue? If so, please explain how. If not, it should > be 5.6+. 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. Although setting new session ID maintains uniqueness of session ID, sessions may lost randomly. The method described in the RFC is required to resolve this issue completely. Otherwise, web site users may experience random lost session. It's very rare though. 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. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
