Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:72877 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 3027 invoked from network); 28 Feb 2014 18:57:35 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 28 Feb 2014 18:57:35 -0000 Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.99 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 108.166.43.99 smtp99.ord1c.emailsrvr.com Linux 2.6 Received: from [108.166.43.99] ([108.166.43.99:36434] helo=smtp99.ord1c.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id F7/E7-64896-E1CD0135 for ; Fri, 28 Feb 2014 13:57:34 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp5.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 986641B2005; Fri, 28 Feb 2014 13:57:31 -0500 (EST) X-Virus-Scanned: OK Received: by smtp5.relay.ord1c.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 103E11B1934; Fri, 28 Feb 2014 13:57:30 -0500 (EST) Message-ID: <5310DC19.2050107@sugarcrm.com> Date: Fri, 28 Feb 2014 10:57:29 -0800 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Yasuo Ohgaki CC: =?UTF-8?B?Sm9oYW5uZXMgU2NobMO8dGVy?= , "internals@lists.php.net" References: <530C3C7B.8080907@sugarcrm.com> <530C77F8.2060809@sugarcrm.com> <1393328380.5233.45.camel@guybrush> <530DD588.1000407@sugarcrm.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Resolution for ver_export()/addslashes() encoding based script execution attack? From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > PHP supports SJIS and the like. Escape functions should provide safe > escaping like databases. The only way to solve this issue is encoding You are making global claims which sound plausible on surface, but when you put them in context, it gets much more complicated. PHP supports SJIS, yes - just as it supports any other existing encoding. That does not mean every scenario possible is automatically working or can be made to work consistently. Specifically, SJIS encoding is not compatible with ASCII encoding, which means same function with same parameters would not work, moreover - choosing parameters which would work in every situation may be quite problematic. > aware escape which databases adopted years ago. I'm proposing known > vulnerability with known method to fix. Encoding-aware inside PHP means different thing than inside the database. The database has only one encoding within the session and doesn't have to deal with anything else. PHP has much more to deal with, especially in scenarios you are proposing - where you are writing out PHP scripts to be executed later. Your solution assumes one set of environment settings and will break in another, current solution works in one set of environment settings and will break in another. So I'm not sure we'll be making much of an improvement there by switching set of cases where it will break. > BTW, users who do not have to worry about this are not affected by > proposed change. That is not the reason to accept the change. It is a necessary, but not a sufficient condition for acceptance. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227