Re: Re: Disabling PHP tags by php.ini and CLI options

From: Date: Wed, 11 Apr 2012 02:51:50 +0000
Subject: Re: Re: Disabling PHP tags by php.ini and CLI options
References: 1 2 3 4  Groups: php.internals 
Request: Send a blank email to internals+get-59701@lists.php.net to get a copy of this message
Hi, I've reorganized benefits in the RFC and would like to share https://wiki.php.net/rfc/nophptags?&#why_this_is_better_than_now 2012/4/11 John Crenshaw <johncrenshaw@priacta.com>: > From: yohgaki@gmail.com [mailto:yohgaki@gmail.com] On Behalf Of Yasuo Ohgaki >> >> Hi, >> >> It seems motivation of this RFC is better to be stated. >> Motivation to have this RFC is >> >> 1. "File Includes" is fatal security breach. >> 2. The reason why PHP is unsecure to "File Include" than other language is >> "Mandatory embed mode" >> 3. Non mandatory embed mode gives option users to better security. >> >> With this RFC, PHP could be as safe as other scripting languages with respect to file >> includes. This RFC is fully compatible with current code. Writing backward compatible code is as few >> as 3 lines. > > No, I understood the reasons, but I reject the assumption that you are making. The "embed > mode" doesn't have a measurable impact on the security of this system. The vulnerable code > can be exploited in countless ways with or without embed mode. You are making bad assumption. If we follow your assumption, we should not implement any mitigation like null byte protection nor open_basedir. Bottom line is LFI is real thread and critical. This RFC provides feasible way to remove the main cause. (i.e. Mandatory embedded mode) > >> Most of security measures are not perfect solutions, but mitigation, just like canary and >> DEP. I suppose people who are concerned with security understand the value of these protections. > > Look, I'm the first to stand up for improved security, but that's now what we have > here. Just calling this a security improvement doesn't make it true. Please read reorganized section and other description in the RFC. > >> Is there any good reasons not to have non mandatory embed mode as a additional security >> measure? Why not to make it harder for attackers to exploit? > > Yes. This fundamentally breaks the language. PHP was first and foremost a template language. In > fact, the strong template integration is a huge part of why one would build a web site in PHP, not > C++. You misunderstood the RFC. It does *NOT* break anything. It's the best of both embedded and non-embedded language. >> In short, I'm really annoyed to hear "PHP is insecure than >> Ruby/Perl/Python/etc" > > Anyone who says this is wrong. Ruby is in fact far less secure, because it doesn't even > have cursory escaping functions and a variety of unpredictable behaviors (implicit returns) can lead > to wild results. Yes, I know where Ruby/Perl/Python can be insecure than PHP. I don't audit Python/Perl much but I do PHP/Ruby (and others) If LFI vulnerability was uncommon, I would not insist this RFC strongly. Mandatory embedded scripting far more insecure than non embedded or optionally embedded languages. I think you misunderstood the RFC, so I reorganized a little. Please read and comment, if any. https://wiki.php.net/rfc/nophptags Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net

« previous php.internals (#59701) next »