Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:90586 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 63253 invoked from network); 13 Jan 2016 01:08:49 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 13 Jan 2016 01:08:49 -0000 Authentication-Results: pb1.pair.com header.from=smalyshev@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=smalyshev@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.45 as permitted sender) X-PHP-List-Original-Sender: smalyshev@gmail.com X-Host-Fingerprint: 209.85.220.45 mail-pa0-f45.google.com Received: from [209.85.220.45] ([209.85.220.45:34565] helo=mail-pa0-f45.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 1B/2C-27877-F93A5965 for ; Tue, 12 Jan 2016 20:08:48 -0500 Received: by mail-pa0-f45.google.com with SMTP id uo6so332299551pac.1 for ; Tue, 12 Jan 2016 17:08:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=r1mrF9tEMErgwy3KNBlDCtFW6RD6oenQ7SYxQPTkZe4=; b=GnTOyF7gLD152m8OLwUsGssHZOYiRgzRRrHpu7QUG3T6wdZ3ZwB0vGANHR04xuOQ24 I8A/Ge6dYSt6A41cadfSzCjGPNxMXv1bqMDO+MAFgmibpFowN/an2s/lmV7LXWAIXpVe vdKldTnQSNDPpAio6z6TQkZWnH2/JnDcY6Hq21Pz1XQtKoNZJ9uFo+7pA4BmokkBrxZa 7cCI8wr6eMDgA8ndxojXv11gMmd+qO9b6VkVAQlZvZhXmc5YHcJzuVjmbh0u/Bd4ObDZ arkYWmTyTwArrAgxUncvO9W/PTLB0QCmfKSZTTop7gvK3DdgDNYNrITAyVQzsgSH5VdX 6/MA== X-Received: by 10.66.142.168 with SMTP id rx8mr191742755pab.16.1452647324602; Tue, 12 Jan 2016 17:08:44 -0800 (PST) Received: from stas-air.corp.wikimedia.org (tan1.corp.wikimedia.org. [198.73.209.1]) by smtp.gmail.com with ESMTPSA id v2sm33014385pfi.93.2016.01.12.17.08.43 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 12 Jan 2016 17:08:43 -0800 (PST) To: Yasuo Ohgaki References: <56958637.5080807@gmail.com> Cc: "internals@lists.php.net" , julien pauli X-Enigmail-Draft-Status: N1110 Message-ID: <5695A39B.4040701@gmail.com> Date: Tue, 12 Jan 2016 17:08:43 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Fixing bug #68063 From: smalyshev@gmail.com (Stanislav Malyshev) 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