php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Doc Bug #73836 unserialize() with $options['allowed_classes'] = null behaves different
Submitted: 2016-12-29 19:04 UTC Modified: 2016-12-30 13:37 UTC
From: denis dot brumann at sensiolabs dot de Assigned: cmb (profile)
Status: Closed Package: Variables related
PHP Version: 7.1.0 OS: macOS Sierra
Private report: No CVE-ID: None
View Add Comment Developer Edit
 [2016-12-29 19:04 UTC] denis dot brumann at sensiolabs dot de 
Description:
------------
I just built a polyfill around the $options parameter added to unserialize() in PHP 7.0. I noticed a different behaviour when allowed_classes is set to null (instead of false) when using PHP 7.0 and 7.1.

See Travis builds:
7.0 (fails) https://travis-ci.org/dbrumann/polyfill-unserialize/jobs/187532454
7.1 (passes) https://travis-ci.org/dbrumann/polyfill-unserialize/jobs/187532455

This is the test that's being executed:
https://github.com/dbrumann/polyfill-unserialize/blob/master/tests/UnserializeTest.php#L74

It seems that PHP 7.1 shows a warning, whereas 7.0 does not. I would expect PHP 7.0 to show the same warning.

Test script:
---------------
$serialized = serialize(new \stdClass());
unserialize($serialized, ['allowed_classes' => null]);

Expected result:
----------------
I would expect both versions to behave the same, either both throw a warning (seems more plausible or neither does).

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2016-12-30 01:00 UTC] cmb@php.net
-Status: Open +Status: Analyzed -Type: Bug +Type: Documentation Problem -Package: Unknown/Other Function +Package: Variables related
 [2016-12-30 01:00 UTC] cmb@php.net 
The warning (and bailing out with FALSE) has been introduced with
the fix of bug #72785, because the supplied test script showed an
unfortunate mistake, which would have caused all classes to be
allowed to be unserialized.

The fix had been only applied to PHP 7.1 for BC reasons, and it
makes sense to treat the warning also this way for the same
reasons.

What is missing, however, are entries in UPGRADING and the
migration guide, plus patching the unserialize() man page. Thus,
I'm changing to doc-bug.

As the other bug has not been classified as security issue, I take
it for granted that unserialize() shouldn't be used on untrusted
user input even if allowed_classes is appropriately set, what
might be mentioned more explicitly in the docs.
 [2016-12-30 13:37 UTC] cmb@php.net 
Automatic comment from SVN on behalf of cmb
Revision: http://svn.php.net/viewvc/?view=revision&revision=341547
Log: Fix #73836: unserialize() with $options['allowed_classes'] = null behaves different
 [2016-12-30 13:37 UTC] cmb@php.net
-Status: Analyzed +Status: Closed -Assigned To: +Assigned To: cmb
 [2020-02-07 06:06 UTC] phpdocbot@php.net 
Automatic comment on behalf of cmb
Revision: http://git.php.net/?p=doc/en.git;a=commit;h=a258daf0ac93754440ff41d78d9f55f132a9cd24
Log: Fix #73836: unserialize() with $options['allowed_classes'] = null behaves different
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Fri Apr 19 21:01:30 2024 UTC