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

From: Date: Mon, 15 Apr 2013 14:26:38 +0000
Subject: Re: [PROPOSAL] add a leading backslash to classname when serializing/var_exporting
References: 1 2 3 4 5 6  Groups: php.internals 
Request: Send a blank email to internals+get-67086@lists.php.net to get a copy of this message
I've seen the usage of signing/hashing stored along side the serialized data to prevent this sort of injection. Still not 100% safe, but in case you really can't escape the use of serialize, it's a start... On Mon, Apr 15, 2013 at 2:52 PM, Thomas Hruska <thruska@cubiclesoft.com>wrote: > 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<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/ > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >

« previous php.internals (#67086) next »