Hi Marco,
Also: nothing denies an attacker from defining a subtype to your class,
> then passing a malicious instance to your application.
Fact, but it also reveals a fragility in the solution in the sense that one
has to opt between flexible design or security.
Em qui, 17 de jan de 2019 às 22:24, Marco Pivetta <ocram...@gmail.com>
escreveu:
>
> On Fri, Jan 18, 2019 at 12:49 AM Marcos Passos <marcospassos....@gmail.com>
> wrote:
>
>> Hi internals,
>>
>> Today I stumbled upon a limitation when implementing the unserialize
>> method
>> of a serializable class which depends on an abstraction also serializable.
>> Currently, there is no way to unserialize an object specifying a parent
>> class in the allowed_classes option:
>>
>> class SerializableBase implements \Serializable {
>> > }
>> > class SerializableChild extends SerializableBase {
>> > }
>> > class Foo implements \Serializable {
>> > private $dependency;
>> > public function __construct(SerializableBase $dependency) {
>> > $this->dependency = $dependency;
>> > }
>> > public function serialize() : string {
>> > return \serialize($this->dependency);
>> > }
>> > public function unserialize($data) : void {
>> > $this->dependency = \unserialize($data, ['allowed_classes' =>
>> > SerializableBase::class]);
>> > }
>> > }
>>
>>
>> Is this an intentional limitation?
>>
>>
> Seems expected to me: `allowed_classes` is a whitelist, not a complex
> filter/ruleset.
>
> Also: nothing denies an attacker from defining a subtype to your class,
> then passing a malicious instance to your application.
>
> Marco Pivetta
>
> http://twitter.com/Ocramius
>
> http://ocramius.github.com/
>
>
