|  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: 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]
Session module is adoptive, so there are chances for session fixation due to 

CVE ID: CVE-2011-4718


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2014-02-12 17:15 UTC]
-CVE-ID: +CVE-ID: 2011-4718
 [2014-02-12 17:15 UTC]
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]
-Assigned To: +Assigned To: yohgaki
 [2014-02-25 01:24 UTC]
yasuo-san, please confirm this can be closed (and marked public).
 [2014-02-25 05:00 UTC]
-Status: Assigned +Status: Closed
 [2014-02-25 05:00 UTC]
This is closed.
Use use_strict_mode=on.
 [2014-02-25 10:40 UTC]
-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]
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]
ļ¼ 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-2023 The PHP Group
All rights reserved.
Last updated: Sat Jun 10 05:03:36 2023 UTC