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
Last revisionBoth sides next revision
rfc:secure_unserialize [2014/11/03 20:59] – stasrfc:secure_unserialize [2015/04/06 20:57] – 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: Implemented
   * 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 35: Line 36:
 $data = unserialize($foo, array("MyClass", "MyClass2"));  $data = unserialize($foo, array("MyClass", "MyClass2")); 
 </code> </code>
 +
 +See API Update below.
  
 ===== Backward Incompatible Changes ===== ===== Backward Incompatible Changes =====
Line 48: Line 51:
   * 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>
 +
 +
 +===== API change =====
 +
 +After some thought and discussion, I have decided to slightly change the API:
 +
 +<code php>
 +// this will unserialize everything as before
 +$data = unserialize($foo); 
 +// this will convert all objects into __PHP_Incomplete_Class object
 +$data = unserialize($foo, ["allowed_classes" => false]); 
 +// this will convert all objects except ones of MyClass and MyClass2 into __PHP_Incomplete_Class object
 +$data = unserialize($foo, ["allowed_classes" => ["MyClass", "MyClass2"]); 
 +//accept all classes as in default
 +$data = unserialize($foo, ["allowed_classes" => true]); 
 +</code>
 +
 +This will allow to extend the options array in the future if we ever want to add more parameters. No objections were voiced on the list regarding this API change.
  
 ===== References ===== ===== References =====
rfc/secure_unserialize.txt · Last modified: 2017/09/22 13:28 by 127.0.0.1

Page Tools