On Fri, Jan 18, 2019 at 1:50 AM Marcos Passos <marcospassos....@gmail.com>
wrote:
> 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/
>>
>>
>
Security is not a choice. The design is not fragile, it is strict and
correct.
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
