Re: [PROPOSAL] add a leading backslash to classname when serializing/var_exporting

From: Date: Mon, 15 Apr 2013 13:52:01 +0000
Subject: Re: [PROPOSAL] add a leading backslash to classname when serializing/var_exporting
References: 1 2 3 4 5  Groups: php.internals 
Request: Send a blank email to internals+get-67085@lists.php.net to get a copy of this message
On 4/14/2013 7:56 PM, Laruence wrote:
hey:
    thanks very much for all feedbacks.
    so,  maybe we should document this instead of adding lead backslash?
thanks On Wed, Apr 10, 2013 at 5:36 AM, Rasmus Lerdorf <rasmus@lerdorf.com> wrote:
On 04/09/2013 01:23 PM, Madara Uchiha wrote:
Well, why would you need to serialize an object in one version of PHP, and unserialize it in another?
serialize()/unserialize() is a convenient, clean, and powerful data transport mechanism for PHP across many sessions and hosts. Using serialize() and unserialize() is an addiction - once someone starts, it is impossible for them to stop. json_encode()/json_decode() can be useful for cross-language support, but they are much more limited. json_decode() has the added natural benefit of not being as vulnerable as unserialize().
people do that all the time. They store serialized versions of stuff in databases and other backends and even send it across the wire from one machine to another, so it is quite common for something serialized in one version to need to be unserialized in another. -Rasmus
While updating the documentation, maybe also include some discussion on the dangers of unserializing data without first establishing trust? There was a discussion not too long ago on this list about PHP executing __destruct() of unserialized class data from untrusted sources. Example recent exploit: http://packetstormsecurity.com/files/118064/invision_pboard_unserialize_exec.rb.txt -- Thomas Hruska CubicleSoft President I've got great, time saving software that you might find useful. http://cubiclesoft.com/

« previous php.internals (#67085) next »