Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:66884 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 43230 invoked from network); 1 Apr 2013 19:46:42 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 1 Apr 2013 19:46:42 -0000 Authentication-Results: pb1.pair.com header.from=steve@mrclay.org; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=steve@mrclay.org; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain mrclay.org from 50.22.11.19 cause and error) X-PHP-List-Original-Sender: steve@mrclay.org X-Host-Fingerprint: 50.22.11.19 bedford.accountservergroup.com Received: from [50.22.11.19] ([50.22.11.19:46002] helo=bedford.accountservergroup.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 25/01-38383-224E9515 for ; Mon, 01 Apr 2013 14:46:42 -0500 Received: from n128-227-233-11.xlate.ufl.edu ([128.227.233.11]:62437 helo=Distance-Ed-Sclay.local) by bedford.accountservergroup.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UMkgh-0001GC-OX for internals@lists.php.net; Mon, 01 Apr 2013 14:46:39 -0500 Message-ID: <5159E41E.7060806@mrclay.org> Date: Mon, 01 Apr 2013 15:46:38 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: PHP Internals References: <5157A55A.1070507@sugarcrm.com> <5157AD1D.3020606@sugarcrm.com> <5159DD93.1010105@sugarcrm.com> In-Reply-To: <5159DD93.1010105@sugarcrm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - bedford.accountservergroup.com X-AntiAbuse: Original Domain - lists.php.net X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - mrclay.org Subject: Re: [PHP-DEV] [RFC] more secure unserialize() From: steve@mrclay.org (Steve Clay) On 4/1/13 3:18 PM, Stas Malyshev wrote: > Why? Making use of one parameter is orders of magnitude easier than > refactoring your whole application to not use serialize() (especially if > you need object support). Under the RFC, unserialize could potentially create __PHP_Incomplete_Class objects (including nested ones), so new handling code would be needed to care for these cases and I wouldn't describe that as a simple fix depending on how the app wants to deal with these cases. IMO these projects would be better off creating drop-in replacements for (un)serialize that wrap in HMAC to secure the data channel. Trivially done in userland. The next best thing would be an unserialize that would simply fail if a non-whitelisted class was found. Steve Clay -- http://www.mrclay.org/