Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:66864 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 91566 invoked from network); 31 Mar 2013 03:27:29 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 31 Mar 2013 03:27:29 -0000 Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.67 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 108.166.43.67 smtp67.ord1c.emailsrvr.com Linux 2.6 Received: from [108.166.43.67] ([108.166.43.67:32931] helo=smtp67.ord1c.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id AB/22-14957-02DA7515 for ; Sat, 30 Mar 2013 22:27:28 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp1.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 2759B148088; Sat, 30 Mar 2013 23:27:26 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp1.relay.ord1c.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id C63B7148072; Sat, 30 Mar 2013 23:27:25 -0400 (EDT) Message-ID: <5157AD1D.3020606@sugarcrm.com> Date: Sat, 30 Mar 2013 20:27:25 -0700 Organization: SugarCRM 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: Sherif Ramadan CC: PHP Internals References: <5157A55A.1070507@sugarcrm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [RFC] more secure unserialize() From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > I think Stas proposes a solution to the problem and I think Anthony > proposes a viable alternative. I would say that Anthony has found the > shortest distance between the two points (the problem and the solution), > however. The fact is that people do use serialize() for data that may be accessible by the user (or made accessible by unrelated security issues, which may be upgraded in severity by this - e.g. from SQL injection to persistent code backdoor on the server). There are many ways to do things differently, and they are known. However, as I said, the fact is people do use serialize() and may not even realize the data aren't as secure as they are. That's why many security tools flag any object with dtor in application using unserialize as insecure. This is not a good situation, and presently there are no way to avoid it except dropping serialize() completely - which may not be an option is some cases and in any case would require serious changes to the production code. This enhancement is to fix this problem. It is not to change best practices or give advice on how to write the most secure system - it is to make existing code more secure easily. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227