Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128397
Feedback-ID: i8414410d:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Tue, 05 Aug 2025 08:22:59 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <795f25eb-3339-4e80-b920-2a336b8b6091@app.fastmail.com>
In-Reply-To: <929642ac-2628-4bdb-acbd-7268231a6e41@app.fastmail.com>
References: <929642ac-2628-4bdb-acbd-7268231a6e41@app.fastmail.com>
Subject: Re: [PHP-DEV] allowed_classes_callback option for unserialize()
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
From: larry@garfieldtech.com ("Larry Garfield")

On Tue, Aug 5, 2025, at 4:14 AM, Casper Langemeijer wrote:
> I'm writing a this email to propose adding allowed_classes_callback 
> option to unserialize(). 
>
> The class name as parsed from the serialized string is passed as a 
> parameter to the callback, it should return a boolean. true would allow 
> the class, false would block it. This blocks classes the same way 
> 'allowed_classes' would, but by callback instead. The callback will be 
> triggered *after* allowed_classes is evaluated (if present). Blocking 
> will have the same effect as allowed_classes, using 
> __PHP_Incomplete_Class.
>
> This callback would solve a few problems where allowed_classes is not 
> sufficient:
>
> - This would also allow for fixing legacy applications where it is not 
> exactly clear what is being unserialized. In my use-case the callable 
> returns a true value but a E_USER_DEPRECATION is triggered. This way 
> data can be collected about what classes to allow through monitoring 
> these deprecations, providing a non-disrupting way to secure 
> unserialize calls. This is especially helpful in very generic 
> unserialize usages like caches.
>
> - It would allow for an is_subclass_of() check where for example an 
> interface can be added to classes that are safe to get unserialized. 
> Current allowed_classes array only matches the exact class, not it's 
> children. 
>
> Note that these problems are not resolvable by using 
> unserialize_callback_func because that call only happens for unloaded 
> classes, where the PHP Object Injection vulnerability 
> https://owasp.org/www-community/vulnerabilities/PHP_Object_Injection 
> affects classes that might already have been loaded.
>
> In de pull request Jakub wrote:
>> Personally I don't see any issue here and it seems quite self contained and small so I wouldn't mind to get it merged without RFC. It might be worth to email internals first to double check that there are no objections first.
>
> Out of scope: I understand that __PHP_Incomplete_Class is not very 
> 2025. Adding an option throw_for_unknown_classes has been suggested on 
> this list. I'm happy to implement that, but for now I'd like to keep it 
> at allowed_classes_callback.
>
> Feedback is very much appreciated.
>
> The change and some more details live here: 
> https://github.com/php/php-src/pull/19087

I am not opposed to this, but I would like to see it go through an RFC.

--Larry Garfield