Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:12585
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Date: Sun, 5 Sep 2004 15:33:28 -0400
Reply-To: Jason Garber <jason@ionzoft.com>
Organization: IonZoft, Inc.
Message-ID: <1379406779.20040905153328@ionzoft.com>
To: Harry Fuecks <hfuecks@gmail.com>
Cc: internals@lists.php.net
In-Reply-To: <e2c74fee04090508296774e6e0@mail.gmail.com>
References: <e2c74fee04090508296774e6e0@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] unserialize() data from untrusted source
From: jason@ionzoft.com (Jason Garber)

Hello Harry,

  This is an interesting point you bring up.  When we have large
  registration processes or similar multi-page forms, we write our
  data array to a hidden field using.

    base64_encode(serialize($aData))

  and read it in with

    unserialize(base64_decode($_POST['aData']))

  passing it from page to page with POST.

  If I understand you correctly, someone could alter the content of
  the serialized array so that it would load a class upon
  unserialization?  If you are auto-loading classes, this might be
  even worse.

  That being the case, I would be much in favor of an optional second
  array parameter to unserialize that would be a list of accepted
  classes, or an empty array to that would (obviously) allow no
  classes (if you were working with simple data types).

    mixed unserialize ( string str[, array classes])

  I'd be interested to hear other comment on this.

-- 
Best regards,
 Jason                            mailto:jason@ionzoft.com

Sunday, September 5, 2004, 11:29:53 AM, you wrote:

HF> Hi All,

HF> Have a situation where I want to unserialize a string received from an
HF> untrusted source over HTTP (a Javascript client in this case). For
HF> basic types this is no concern but when it comes to objects, would be
HF> nice to be able to restrict the class of object to a member of a known
HF> list, to prevent "unplanned objects" being created from classes which
HF> happened to be defined but were not intended for unserialization (such
HF> as the growing number pre-loaded classes in PHP5), and the possible
HF> security issues that might introduce.

HF> Checking the type of class once the object has been created might be
HF> too late, depending on what the constructor does. That leaves manually
HF> parsing the serialized string in PHP, before called unserialize, as
HF> the only really safe option.

HF> Could be this is outside of the scope of intended use of unserialize()
HF> but PHP's serialized representation of data makes a pretty nice
HF> encoding for exchange with other systems and I notice others doing the
HF> same e.g.;

HF> http://www.aagh.net/projects/ruby-php-serialize
HF> http://hcs.harvard.edu/~pli/code/serialPHP.pm
HF> http://www.cpan.org/modules/by-module/PHP/JBROWN/php-serialization/
HF> http://hurring.com/code/perl/serialize/

HF> Serialized data is also often used with sessions which means the usual
HF> issues with shared hosts and session files (OK - smarter users avoid
HF> this but...)

HF> Perhaps unserialize could take a second (optional) argument which is a
HF> list of allowed classes to validate against.

HF> Many thanks,

HF> Harry