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. 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 <? 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. 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. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
