rfc:secure_unserialize
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
rfc:secure_unserialize [2014/10/27 07:58] – stas | rfc:secure_unserialize [2014/11/03 20:59] – stas | ||
---|---|---|---|
Line 10: | Line 10: | ||
unserialize() in PHP has certain security issues, brought by the fact that serialized data can | unserialize() in PHP has certain security issues, brought by the fact that serialized data can | ||
include objects with data, and once these objects are instantiated, | include objects with data, and once these objects are instantiated, | ||
- | are destroyed. This could allow to inject serialized data into application which may perform actions not intended by application writer, such as carelessly assuming unserialized data have certain types and calling functions on them which may have different meaning for different objects. Besides destructors, | + | are destroyed. This could allow to inject serialized data into application which may perform actions not intended by application writer, such as carelessly assuming unserialized data have certain types and calling functions on them which may have different meaning for different objects. Besides destructors, |
It is true that best security guidelines recommend to not use unserialize() on untrusted data, but this is mainly because of the missing filtering mechanisms in unserialize(). The fact also is that many applications depend on using unserialize() and are not going to be changed, at least in the short term, to use other mechanisms, especially in areas where object support is still needed. Thus, I think it still makes sense to provide filtered unserialize() in order to allow people reasonable alternative without having them to resort to things like PHP implementation of unserialize() (e.g. see https:// | It is true that best security guidelines recommend to not use unserialize() on untrusted data, but this is mainly because of the missing filtering mechanisms in unserialize(). The fact also is that many applications depend on using unserialize() and are not going to be changed, at least in the short term, to use other mechanisms, especially in areas where object support is still needed. Thus, I think it still makes sense to provide filtered unserialize() in order to allow people reasonable alternative without having them to resort to things like PHP implementation of unserialize() (e.g. see https:// | ||
Line 22: | Line 22: | ||
* 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 |
If the class for the object is not allowed, the object is unserialized as an object of " | If the class for the object is not allowed, the object is unserialized as an object of " | ||
Line 42: | Line 42: | ||
===== 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 |
===== Other issues ==== | ===== Other issues ==== | ||
rfc/secure_unserialize.txt · Last modified: 2017/09/22 13:28 by 127.0.0.1