Re: [PROPOSAL] add a leading backslash to classname when serializing/var_exporting
| From: | Thomas Hruska | 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: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().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?
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/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