Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:73097 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 4488 invoked from network); 13 Mar 2014 04:04:01 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 13 Mar 2014 04:04:01 -0000 Authentication-Results: pb1.pair.com header.from=yohgaki@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=yohgaki@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.172 as permitted sender) X-PHP-List-Original-Sender: yohgaki@gmail.com X-Host-Fingerprint: 209.85.217.172 mail-lb0-f172.google.com Received: from [209.85.217.172] ([209.85.217.172:38146] helo=mail-lb0-f172.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id A1/93-17655-F2E21235 for ; Wed, 12 Mar 2014 23:04:00 -0500 Received: by mail-lb0-f172.google.com with SMTP id c11so287474lbj.31 for ; Wed, 12 Mar 2014 21:03:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:content-type; bh=50VRb85Xih1v1h13oGxVHU0SGjrbXfOg0bFhTWcOx8U=; b=Z1dW3fOQwA86tdoUl5UdBSpmC905+7UgKw4fjVJAYMSbimKH37yDJteynfx7uT3w74 ORfUfTlXP9S/H5dE4oOqgDHSY5F2XpJZhkZoQK8KlyKp5uE46eJINisY/4CyqTy3s2jo CS3fnRlrejfYFVB9OnXJHxuwsxWHpQo2YNDQyoaAeSDLmwyPyERDHJtAOtifPVAaf/M3 v2uV+eHuQnA5d5awmG5NWI9/tov6dKbaM5zZNWUHq8VfLpvUjK8Ue1aEEFDvTqJgF2D9 l0akRESP71W+Xst2XUdCa6Lu+m6d6NN9/+wslqQDQ6UGgy8BNiQ4VlVgqSAsIPHV6aT1 imJw== X-Received: by 10.112.28.82 with SMTP id z18mr787997lbg.18.1394683436385; Wed, 12 Mar 2014 21:03:56 -0700 (PDT) MIME-Version: 1.0 Sender: yohgaki@gmail.com Received: by 10.112.205.73 with HTTP; Wed, 12 Mar 2014 21:03:15 -0700 (PDT) Date: Thu, 13 Mar 2014 13:03:15 +0900 X-Google-Sender-Auth: E-Ry7PDW04x7t2yERwfqphWxWkY Message-ID: To: "internals@lists.php.net" Content-Type: multipart/alternative; boundary=001a1133e8ecccc96504f4750a97 Subject: Solution for session_regenerate_id() issues From: yohgaki@ohgaki.net (Yasuo Ohgaki) --001a1133e8ecccc96504f4750a97 Content-Type: text/plain; charset=UTF-8 Hi all, Current session_regenerate_id() has issues. I'll try to explain what these are. Issue 1: Old session data is not deleted. session_regenerate_id() does not delete old session by default. It leaves old session available. When attacker could steal session ID via XSS/sniffing/etc, attacker can use session ID as valid ID as long as application allows. No detection/prevention of security breach is possible at session module level. This behavior is unacceptable for security reason. Issue 2: Old session data cannot be deleted. session_regenerate_id(TRUE) deletes old session data immediately. It's good for security, but if there are multiple connections from a client to server (e.g. AJAX/iframe/tabs/etc), valid connection may fail since it could be using old session ID. Therefore, session_regenerate_id() does not delete old session data. Immediate session data deletion is unacceptable for reliable operation. To solve these 2 issues, we need to delay old session data deletion. Delete old session data 60 seconds later, for example. If there is any other feasible solutions are welcome. I cannot think of any. Regards, P.S. Even with HTTP 2.0, old session data cannot be deleted immediately. User may use multiple tabs. -- Yasuo Ohgaki yohgaki@ohgaki.net --001a1133e8ecccc96504f4750a97--