Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:12579 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 43117 invoked by uid 1010); 5 Sep 2004 15:33:54 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 36820 invoked from network); 5 Sep 2004 15:29:55 -0000 Received: from unknown (HELO mproxy.gmail.com) (64.233.170.205) by pb1.pair.com with SMTP; 5 Sep 2004 15:29:54 -0000 Received: by mproxy.gmail.com with SMTP id 75so114305rnl for ; Sun, 05 Sep 2004 08:29:53 -0700 (PDT) Received: by 10.38.86.78 with SMTP id j78mr949168rnb; Sun, 05 Sep 2004 08:29:53 -0700 (PDT) Received: by 10.38.13.33 with HTTP; Sun, 5 Sep 2004 08:29:53 -0700 (PDT) Message-ID: Date: Sun, 5 Sep 2004 17:29:53 +0200 Reply-To: Harry Fuecks To: internals@lists.php.net Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: unserialize() data from untrusted source From: hfuecks@gmail.com (Harry Fuecks) Hi All, Have a situation where I want to unserialize a string received from an untrusted source over HTTP (a Javascript client in this case). For basic types this is no concern but when it comes to objects, would be nice to be able to restrict the class of object to a member of a known list, to prevent "unplanned objects" being created from classes which happened to be defined but were not intended for unserialization (such as the growing number pre-loaded classes in PHP5), and the possible security issues that might introduce. Checking the type of class once the object has been created might be too late, depending on what the constructor does. That leaves manually parsing the serialized string in PHP, before called unserialize, as the only really safe option. Could be this is outside of the scope of intended use of unserialize() but PHP's serialized representation of data makes a pretty nice encoding for exchange with other systems and I notice others doing the same e.g.; http://www.aagh.net/projects/ruby-php-serialize http://hcs.harvard.edu/~pli/code/serialPHP.pm http://www.cpan.org/modules/by-module/PHP/JBROWN/php-serialization/ http://hurring.com/code/perl/serialize/ Serialized data is also often used with sessions which means the usual issues with shared hosts and session files (OK - smarter users avoid this but...) Perhaps unserialize could take a second (optional) argument which is a list of allowed classes to validate against. Many thanks, Harry