Hi, 2012/4/11 Stas Malyshev <smalys...@sugarcrm.com>: > Hi! > >> If attacker can inject code at the beginning or make valid syntax >> at the beginning, they can succeed injection. This is true not >> only for PHP, but also Ruby/Perl/Python. > > This is exactly my point. Since it does not solve the problem that you > are presenting (I am still not convinced it's our problem, but for the > same of discussion let's assume for now it is so) - why exactly would we > want to do it? I'm afraid we'd have another safe_mode scenario on our > hands here, where we lure users into complacency with false sense of > security, while not actually providing it.
safe_mode was security measure in first place. (I liked it as fail safe feature. The name should have been fail_safe_mode) 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! 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. For this respect, template_mode=on is like prepared query. Prepared query is *NOT* designed as a security measure, but for better performance. Prepared query is not a perfect SQL injection countermeasure as it never escape nor parameterize identifiers/SQL literals. It works well as a security measure for most cases, though. There are many features that is used or considered as security measure that aren't a perfect or designed for it. We have to be careful about this so that PHP programmers do not misunderstood LFI prevention is not required anymore, if we are going adopt this RFC for next PHP. PHP could be stronger against LFI compare to scripting languages as I described in previous mail. With this RFC, infamous reputation of LFI can be removed from PHP! I hope most of us will accept this RFC, if it is not all. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
