Hey Rasmus, Here are my thoughts:
On Apr 11, 2012, at 7:09 AM, Rasmus Lerdorf <ras...@lerdorf.com> wrote: > On 04/11/2012 12:59 AM, Stas Malyshev wrote: >>> 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. > > I guess he is saying that it prevents: > > Random bytes > <?php kill();?> > More random bytes > > Where random bytes might be an image file so finfo_file() might identify > it as a valid image whereas it doesn't prevent: > > <?php kill();?> > Random bytes > > from being mistakenly included. And I guess a secondary thing it might > prevent is an include of something like /etc/passwd since there is no > valid PHP code there and it would error out. Isn't this determined by the web server, not PHP? The only way this would happen is if image files were sent to the PHP interpreter or the image had a .php. In both cases it's the server admins responsibility to make sure the web server doesn't send any file from an upload folder to the PHP interpreter, with a .PHP extension or not. The programmer should also be mindful of what extensions are being allowed to go in the upload folder incase the server admin was negligent. The only benefit is only having to check the start of the file for a <?php tag. But if both the programmer and server admin are being negligent this benefit is moot. > So, those are the pros. The cons are: > > 1. Creating a new mode for PHP that essentially breaks most existing PHP > code if this mode is enabled puts more pressure on people trying to > write portable code. It would encourage them to never use templating > mode since non-templating mode is the only safe approach that would work > regardless of the configuration. Much the same way that all portable > code uses <?php and no <? Tom has a "similar" RFC that has two modes: - Template mode - how it is now - Code (or pure code) mode - <?php is only allowed at the top and is optional. ?> is disallowed. Tom's RFC calls for template mode to remain the default, but allow you to add a flag to require/include to interpret the script in "pure mode". Allowing an optional starting <?php (only at top) maintains backwards compatibility with most classes. The benefit is not having to write <?php and forbidding ?> in the middle of a class (which most people already do voluntarily). > 2. Templating is a defining characteristic of PHP. For many people it is > the primary reason they even use PHP. Adding a feature that would > essentially discourage use of a defining feature of PHP is illogical. True. People are side stepping this though for template engines such as Twig, PHPTAL, Smarty (ug..), just to name a few. PHP is being used more as a programming language than a template engine. People have already naturally gravitated towards keeping their code separate. Toms proposal of a code and template mode makes sense. It clearly separates the two. You could theoretically enhance the template part. Like I love the idea of PHPTAL - I wrote a similar template engine that uses attributes to convey logic (data-if, for example). Attribute syntax preserves the design of a template. Right now I have to parse this and convert this to a PHP class. Wouldn't it be great if PHP did this in its template mode? Or easily allowed people to provide alternate "template engines" that required no pre-parsing in PHP (other than the usual code to opcode transformation)? > 3. For the /etc/passwd case, the syntax error might reveal enough data > about the contents of the file that this doesn't actually provide enough > of a benefit unless we also heavily redact what we show in a syntax > error. Of course, the argument here is not to show the error to users, > but people who write code with include $_GET['filename'] aren't likely > to follow best practices in the first place. > > 4. Only protecting against mid-script injections and not top-of-script > injections is a somewhat subtle concept when the real problem is the > vulnerable include $_GET['filename'] hole. If this really is a prevalent > problem, maybe instead of trying to mitigate the symptoms, why don't we > try to attack the actual cause of the problem. I would love to hear some > ideas along those lines that don't fundamentally change the nature of > PHP for somewhat cloudy benefits. The problem is people are doing that. The solution is they should stop doing that. Anyone doing this is asking for trouble. The fix is better education. In the end while I do support the idea of not allowing "embed mode" (as a choice when doing require/include), I cannot support the idea that it somehow makes things more secure. Luke -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
