php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #60491 Session module is adoptive
Submitted: 2011-12-10 00:52 UTC Modified: 2015-01-08 06:40 UTC
From: yohgaki@php.net Assigned: yohgaki (profile)
Status: Closed Package: Session related
PHP Version: Irrelevant OS: All
Private report: No CVE-ID: 2011-4718
 [2011-12-10 00:52 UTC] yohgaki@php.net
Description:
------------
Session module is adoptive, so there are chances for session fixation due to 
adoption.

CVE ID: CVE-2011-4718

https://wiki.php.net/rfc/strict_sessions


Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2014-02-12 17:15 UTC] tyrael@php.net
-CVE-ID: +CVE-ID: 2011-4718
 [2014-02-12 17:15 UTC] tyrael@php.net
this should be closed, as it is fixed since 5.5.2 with the addition of the strict sessions, right?
 [2014-02-25 01:24 UTC] johannes@php.net
-Assigned To: +Assigned To: yohgaki
 [2014-02-25 01:24 UTC] johannes@php.net
yasuo-san, please confirm this can be closed (and marked public).
 [2014-02-25 05:00 UTC] yohgaki@php.net
-Status: Assigned +Status: Closed
 [2014-02-25 05:00 UTC] yohgaki@php.net
This is closed.
Use use_strict_mode=on.
 [2014-02-25 10:40 UTC] johannes@php.net
-Type: Security +Type: Feature/Change Request
 [2014-12-30 02:05 UTC] yqbjtu at 163 dot com
is PHP5.4 affected by this CVE-2011-4718?  I see it is fixed in 5.5.2.  but how about the php 5.4 serials, such as the latest php 5.4.36?  Thank you!
 [2015-01-07 00:48 UTC] yohgaki@php.net
For the record, this issue can be avoided by calling session_regenerate_id() properly. e.g. Regenerate session ID upon login/when item is put in cart at first time, etc. 

With use_strict_mode=On, programmer does not have to care for adoptive session manager. When use_strict_mode=Off, programmer must care for adoptive session manager.
 [2015-01-08 02:51 UTC] liutj at cn dot ibm dot com
Does it means if we never used the method session_regenerate_id(), our product will not be affected by CVE-2011-4718
 [2015-01-08 06:40 UTC] yohgaki@php.net
ļ¼ liutj 
Yes, you are.

If you are using tran_sid, impact is severe. If you are using only cookie, impact is moderate as typical attack needs JavaScript vulnerability. Note that your colleague may able to set cookie locally by manipulating browser's cookie database directly. It does not require JavaScript vulnerability with this method. If you are using http only cookie, risk is relatively low since JavaScript injection cannot modify session cookie. However, IE had strange cookie priority when I checked it years ago. HTTP only cookie may not help with IE.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Nov 21 12:01:29 2024 UTC