Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:67086
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.178 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <516C0601.7060003@cubiclesoft.com>
References: <CABBJUpepz+TU-Y6oFkpv9sJ84-Rtf_yrXPN=KpVTMBmK2ZMsFw@mail.gmail.com>
 <51647536.6030108@sugarcrm.com> <CAGbiJu-qg8d4pdYQyeDTwE=dPPzmSjXZUwqRtz7jOSoYsx3L3Q@mail.gmail.com>
 <516489F1.70106@lerdorf.com> <CABBJUpcrVNOAqT7jRz2q1CkTa6zt_Be0-Hy-9AuZZvHx6Q9erw@mail.gmail.com>
 <516C0601.7060003@cubiclesoft.com>
Date: Mon, 15 Apr 2013 15:26:38 +0100
Message-ID: <CA+yzxZivCtgryo0+iA9K+nDy6ZNtquUOXa-HrE-H=8fm4FHukw@mail.gmail.com>
To: Thomas Hruska <thruska@cubiclesoft.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=e89a8f646d15dcbb7804da670c77
Subject: Re: [PHP-DEV] [PROPOSAL] add a leading backslash to classname when serializing/var_exporting
From: admacedo@gmail.com (Daniel Macedo)

--e89a8f646d15dcbb7804da670c77
Content-Type: text/plain; charset=ISO-8859-1

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
>
>

--e89a8f646d15dcbb7804da670c77--