rfc:secure_unserialize
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
rfc:secure_unserialize [2014/11/03 20:59] – stas | rfc:secure_unserialize [2017/09/22 13:28] (current) – external edit 127.0.0.1 | ||
---|---|---|---|
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: | + | * Status: |
* First Published at: http:// | * First Published at: http:// | ||
* Patch: https:// | * Patch: https:// | ||
+ | |||
===== Introduction ===== | ===== Introduction ===== | ||
Line 35: | Line 36: | ||
$data = unserialize($foo, | $data = unserialize($foo, | ||
</ | </ | ||
+ | |||
+ | 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=" | ||
+ | * Yes | ||
+ | * No | ||
+ | </ | ||
+ | |||
+ | |||
+ | ===== 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, | ||
+ | // this will convert all objects except ones of MyClass and MyClass2 into __PHP_Incomplete_Class object | ||
+ | $data = unserialize($foo, | ||
+ | //accept all classes as in default | ||
+ | $data = unserialize($foo, | ||
+ | </ | ||
+ | |||
+ | 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.1415048343.txt.gz · Last modified: 2017/09/22 13:28 (external edit)