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 [2013/03/30 05:21] – [Backward Incompatible Changes] stas | rfc:secure_unserialize [2014/10/27 07:47] – 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: | + | * Status: |
| * First Published at: http:// | * First Published at: http:// | ||
| + | * Patch: https:// | ||
| ===== Introduction ===== | ===== Introduction ===== | ||
| Line 37: | Line 37: | ||
| * No user-level BC issues should arise, as the default mode functions exactly as unserialize() works now. | * No user-level BC issues should arise, as the default mode functions exactly as unserialize() works now. | ||
| - | * It is not clear yet it it's possible to preserve binary API with this change. | ||
| - | ===== Proposed PHP Version(s) ===== | ||
| - | The change can be merged into any PHP version since it does not involve backwards-incompatible changes either on API level or on language level. | + | ===== Proposed |
| + | Since the current patch preserves the binary API, the change can be merged into any PHP version. | ||
| ===== 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. | + | * 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. |
| ===== References ===== | ===== References ===== | ||
| Line 52: | Line 51: | ||
| * Example of unserialize() security issue: http:// | * Example of unserialize() security issue: http:// | ||
| + | ===== See also ===== | ||
| + | * Joomla unserialize() vulnerability: | ||
| + | * CubeCart unserialize() vulnerability: | ||
| + | * TikiWiki unserialize() vulnerability: | ||
| + | * Invision Power Board unserialize() vulnerability: | ||
| ===== Changelog ===== | ===== Changelog ===== | ||
| - 2013-03-29 First version published | - 2013-03-29 First version published | ||
rfc/secure_unserialize.txt · Last modified: 2017/09/22 13:28 by 127.0.0.1