rfc:secure_unserialize

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
Next revisionBoth sides next revision
rfc:secure_unserialize [2014/10/27 08:00] stasrfc:secure_unserialize [2014/11/17 00:55] stas
Line 3: Line 3:
   * Date: 2013-03-29    * Date: 2013-03-29 
   * Author: Stas Malyshev, stas@php.net   * Author: Stas Malyshev, stas@php.net
-  * Status: In Discussion +  * Status: Voting
   * First Published at: http://wiki.php.net/rfc/secure_unserialize   * First Published at: http://wiki.php.net/rfc/secure_unserialize
   * Patch: https://github.com/php/php-src/pull/315   * Patch: https://github.com/php/php-src/pull/315
 +
 ===== Introduction ===== ===== Introduction =====
  
Line 22: Line 23:
   * true - default value, allows all objects just as before   * true - default value, allows all objects just as before
   * false - no objects allowed   * false - no objects allowed
-  * array of class names, which list the allowed classes for unserialized objects+  * array of class names, which list the allowed classes for unserialized objects (empty array here means the same as false)
  
 If the class for the object is not allowed, the object is unserialized as an object of "incomplete class", just as it is done in a case where object's class does not exist. This means that the serialized data are roundtrip-safe with any settings, but with added security settings the unintended objects will not be accessible and their destructors and other methods will not be called.  If the class for the object is not allowed, the object is unserialized as an object of "incomplete class", just as it is done in a case where object's class does not exist. This means that the serialized data are roundtrip-safe with any settings, but with added security settings the unintended objects will not be accessible and their destructors and other methods will not be called. 
Line 42: Line 43:
 ===== Proposed PHP Version(s) ===== ===== Proposed PHP Version(s) =====
  
-Proposed for inclusion into PHP 5.6.x or PHP 7 branches.+Proposed for inclusion into PHP 7 branch, and into  PHP 5.6.x provided the RM approves it and there will be no substantial objections to that. 
 ===== Other issues ==== ===== Other issues ====
  
   * It is not planned that unserialize_callback_func function will be called on prohibited classes as it is done on non-existing classes.    * It is not planned that unserialize_callback_func function will be called on prohibited classes as it is done on non-existing classes. 
   * This option is not available currently for sessions and any other functions that use unserialization without calling unserialize(). This may be added later if needed, but for sessions it is very unlikely that untrusted user data will be injected as serialized session data - in that case the problems with security are much larger as pretty much any session-based authentication will be immediately broken.     * This option is not available currently for sessions and any other functions that use unserialization without calling unserialize(). This may be added later if needed, but for sessions it is very unlikely that untrusted user data will be injected as serialized session data - in that case the problems with security are much larger as pretty much any session-based authentication will be immediately broken.  
 +
 +===== Vote =====
 +
 +The vote is to accept the unserialize() filtering option as described in this RFC for inclusion into PHP, with options being Yes or No. 50%+1 majority is required for acceptance.
 +
 +Vote started on 2014-11-03 and is open until 2014-11-10 23:59:59 PST. 
 +
 +<doodle title="Approve filtered unserialize() proposal?" auth="stas" voteType="single" closed="true">
 +   * Yes
 +   * No
 +</doodle>
 +
  
 ===== References ===== ===== References =====
rfc/secure_unserialize.txt · Last modified: 2017/09/22 13:28 by 127.0.0.1