Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:59726 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 4980 invoked from network); 11 Apr 2012 07:59:32 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 11 Apr 2012 07:59:32 -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 67.192.241.123 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 67.192.241.123 smtp123.dfw.emailsrvr.com Linux 2.6 Received: from [67.192.241.123] ([67.192.241.123:57990] helo=smtp123.dfw.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 9D/67-18401-4E9358F4 for ; Wed, 11 Apr 2012 03:59:32 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp2.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 50D0A78139; Wed, 11 Apr 2012 03:59:28 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp2.relay.dfw1a.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id C98BB780FF; Wed, 11 Apr 2012 03:59:27 -0400 (EDT) Message-ID: <4F8539E0.1090701@sugarcrm.com> Date: Wed, 11 Apr 2012 00:59:28 -0700 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: Yasuo Ohgaki CC: "internals@lists.php.net" References: <4F850D06.10701@sugarcrm.com> <4F8515AF.8060706@sugarcrm.com> <4F851FE4.7000706@sugarcrm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Re: Disabling PHP tags by php.ini and CLI options From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > template_mode=on is not a actual security measure, but a > switch for language mode. template_mode=on has side > effect that makes PHP as safe as other scripting languages > or even better! PHP is as safe as other scripting languages right now. And you are using security talk to promote this proposal, including in this very email. If you don't see it as security feature, please do not talk about it as a security feature. > Therefore, it should not be misunderstood as perfect LFI > countermeasure even if I stressed on security meanings. > I'm stressing security because this actually helps PHP being > much safer than now. I don't see how it is "much safer". Exactly the same problem exists. Not only it is not "perfect" countermeasure, it's not countermeasure at all, judging from your description. It's like saying "I have SQL injection protection, but only if word "please" is not part of the SQL injection". It's not a real protection then. > PHP could be stronger against LFI compare to scripting languages > as I described in previous mail. PHP is as strong as any other language right now - if you include user-supplied code, you lost, don't do it - no problem. > With this RFC, infamous reputation of LFI can be removed from PHP! I see no "infamous reputation" except the wrong one you are creating right now. include with user-supplied argument is a security hole, it has nothing to do with vulnerability in PHP. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227