Re: [PROPOSAL] add a leading backslash to classname when serializing/var_exporting
| From: | Daniel Macedo | 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
>
>