Re: Unserializes, inheritance and allows_classes

From: Date: Fri, 18 Jan 2019 01:00:48 +0000
Subject: Re: Unserializes, inheritance and allows_classes
References: 1 2 3 4  Groups: php.internals 
Request: Send a blank email to internals+get-103760@lists.php.net to get a copy of this message
How would you fix this example, then? Perhaps we should add more examples in the docs. Em qui, 17 de jan de 2019 às 22:53, Marco Pivetta <ocramius@gmail.com> escreveu: > On Fri, Jan 18, 2019 at 1:50 AM Marcos Passos <marcospassos.com@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 <ocramius@gmail.com> >> escreveu: >> >>> >>> On Fri, Jan 18, 2019 at 12:49 AM Marcos Passos < >>> marcospassos.com@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/ > >

« previous php.internals (#103760) next »