rfc:strict_sessions

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
rfc:strict_sessions [2013/08/05 10:25] – [Request for Comments: Strict Sessions] yohgakirfc:strict_sessions [2017/09/22 13:28] (current) – external edit 127.0.0.1
Line 3: Line 3:
   * Date: 2011-12-02   * Date: 2011-12-02
   * Author: Yasuo Ohgaki <yohgaki@ohgaki.net>   * Author: Yasuo Ohgaki <yohgaki@ohgaki.net>
-  * Status: Applied to 5.5.3+  * Status: Applied to 5.5.2
   * First Published at: https://wiki.php.net/rfc/strict_sessions   * First Published at: https://wiki.php.net/rfc/strict_sessions
  
Line 27: Line 27:
 This patch adds This patch adds
   * validate_sid() to ps_modules (Save handlers)   * validate_sid() to ps_modules (Save handlers)
-  * use_strict_session to php.ini (On by default, off for old behavior)+  * session.use_strict_mode to php.ini (On by default, off for old behavior)
   * display that save handler supports strict session or not via phpinfo() (So that user could know behavior)   * display that save handler supports strict session or not via phpinfo() (So that user could know behavior)
   * update PHP_SESSION_API version (So that save handler authors could write portable code)   * update PHP_SESSION_API version (So that save handler authors could write portable code)
Line 35: Line 35:
  
   * save handlers that are currently working should also work with this patch, except ps modules using PS_MOD_SID and PS_MOD_FUNCS_SID macro. These ps modules should implement validate_sid(). Modules that are using PS_MOD/PS_FUNCS are not affected, they just marked as "adaptive" module. (e.g. pecl sqlite's ps module. You can see it via phpinfo()) NOTE: PS_MOD_SID() and PS_MOD_FUNCS_SID() are already defined, but it was the same as PS_MOD()/PS_MOD_FUNCS(). If old ps_module that uses PS_MOD_SID()/PS_MOD_FUNCS_SID() does not compile, implement validate_id().   * save handlers that are currently working should also work with this patch, except ps modules using PS_MOD_SID and PS_MOD_FUNCS_SID macro. These ps modules should implement validate_sid(). Modules that are using PS_MOD/PS_FUNCS are not affected, they just marked as "adaptive" module. (e.g. pecl sqlite's ps module. You can see it via phpinfo()) NOTE: PS_MOD_SID() and PS_MOD_FUNCS_SID() are already defined, but it was the same as PS_MOD()/PS_MOD_FUNCS(). If old ps_module that uses PS_MOD_SID()/PS_MOD_FUNCS_SID() does not compile, implement validate_id().
-  * session ID string is checked so that chars are alphanumeric + ',','-' when use_strict_session=On. (mod_file.c checks session ID this way w/o this patch to prevent+  * session ID string is checked so that chars are alphanumeric + ',','-' when session.use_strict_mode=On. (mod_file.c checks session ID this way w/o this patch to prevent
 problems. Using restrictive session ID string is better for other ps modules. IMHO) problems. Using restrictive session ID string is better for other ps modules. IMHO)
   * session read failure is not rescued to eliminate possible infinite loops. Bundled ps modules were not using this at least.   * session read failure is not rescued to eliminate possible infinite loops. Bundled ps modules were not using this at least.
Line 42: Line 42:
 session. By looking into failing test results, you can see this patch session. By looking into failing test results, you can see this patch
 is generating new session ID if it's not a already initialized is generating new session ID if it's not a already initialized
-session. I'll modify these tests (set use_strict_session=Off) and add+session. I'll modify these tests (set session.use_strict_mode=Off) and add
 some tests for new feature (new validate_sid() function for user and some tests for new feature (new validate_sid() function for user and
 use_class save handler) after commit. use_class save handler) after commit.
Line 149: Line 149:
 order preference for sending cookies than Chrome/Firefox. order preference for sending cookies than Chrome/Firefox.
  
-This behavior prevents use of session_regenerat_id()'s new cookie in some cases. PHP may +This behavior prevents use of session_regenerate_id()'s new cookie in some cases. PHP may 
 use invalid session ID to initialize session. Session ID can be fixed (i.e. session fixation)  use invalid session ID to initialize session. Session ID can be fixed (i.e. session fixation) 
 without the validation code. without the validation code.
Line 165: Line 165:
   * First cookie(C=%2Fwww%2Fdefault%2Fpublic) is cookie set without domain and the default path '/'   * First cookie(C=%2Fwww%2Fdefault%2Fpublic) is cookie set without domain and the default path '/'
   * Second cookie(C=test.co.jp) is cookie set with domain.    * Second cookie(C=test.co.jp) is cookie set with domain. 
-  * In this case, PHP initialize $_COOKIE['C'] == 'test.co.jp'. Session is also initializes with second cookie regardless of cookie set for path.+  * In this case, PHP initialize $_COOKIE['C'] == 'test.co.jp'. Session is also initialized with second cookie regardless of cookie set for path.
   * Cookies are set for all combinations with different values (domain name and full path dir). (i.e. all domain and path)     * Cookies are set for all combinations with different values (domain name and full path dir). (i.e. all domain and path)  
-  * To make this happen, it seems order of setting cookies were significant. Set path first, then domain. +  * To make this happen, it seems order of setting cookies was significant. Set path first, then domain. 
  
  
Line 181: Line 181:
   Cookie: C=co.jp   Cookie: C=co.jp
  
-  * This is an test case for invalid domain. co.jp is ccTLD so browser should not set cookie for it. However, browser seems set cookie if it has IP.+  * This is test case for invalid domain. co.jp is ccTLD so browser should not set cookie for it. However, browser seems set cookie if it has IP.
   * This is very handy if someone wants to steal him/her colleague session. Just edit hosts and set long life cookie for the domain. It will remain unless cookie is expired or explicitly deleted.   * This is very handy if someone wants to steal him/her colleague session. Just edit hosts and set long life cookie for the domain. It will remain unless cookie is expired or explicitly deleted.
  
Line 196: Line 196:
   * http://www.mail-archive.com/internals@lists.php.net/msg54147.html   * http://www.mail-archive.com/internals@lists.php.net/msg54147.html
   * http://www.mail-archive.com/internals@lists.php.net/msg54761.html   * http://www.mail-archive.com/internals@lists.php.net/msg54761.html
 +
 +===== Implementation =====
 +
 +  * https://github.com/php/php-src/commit/25e8fcc88fa20dc9d4c47184471003f43
 +  * https://github.com/php/php-src/commit/82b0e8be99065b61b622df2
  
  
rfc/strict_sessions.1375698305.txt.gz · Last modified: 2017/09/22 13:28 (external edit)