Hi, 2012/4/11 Stas Malyshev <smalys...@sugarcrm.com>: > 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.
It is just like saying "Java is more secure than C" C is danger than Java by its nature due to memory management. PHP is danger than others by its mandatory embedded scripting. Not like others, PHP exposes whatever files with permission with include $_GET['var']; I agree it's not a security feature, but language nature. However, it is not reasonable that not to emphasise one of the most important benefit, isn't it? > >> 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. There are only few perfect solutions for security. Neither null byte protection nor allow_url_include are not a perfect solutions. (allow_url_include may be improved. Or is it already?) > >> 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. This argument will be true for most of security countermeasures. Anyway, non mandatory scripting could be think as a security countermeasure, but it's side effect. > >> 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. Once again, it's the same for null byte protection. I really like the null byte protection. I think it's brilliant. I don't know about your country, but I know many developers/users who think PHP is dangerous because of easy LFI. According to basic risk manage textbook, risk is a formula that consists by "Damage when indent happened" and "The probability that a incident happens". Damage of LFI: extreme (code execution/massive information disclosure) Probability of LFI: common This fact makes me to impossible to ignore the risk. Since other people is discussing for having script only files, considering to remove the known risk is reasonable act, I suppose. I've spent a lot of time to describe how PHP users could be protected from real life risk in the RFC. I hope you are not against basic risk management principle. You don't have to think of this RFC as security countermeasure, but the effect of the RFC adoption should be considered. I argue this RFC with respect to security, since security is the primary motivation of this RFC to me. Applications like Wordpress and other countless PHP apps are at the great risk, since there are many developers including novice. Why we shouldn't consider security benefits of the RFC? Regards, P.S. You might have missed SQL injection and LFI. (See bottom part of Introduction) https://wiki.php.net/rfc/nophptags?&#introduction SQL injections and LFI is common PHP app vulnerability. I've updated a lot, please read at least this section also. https://wiki.php.net/rfc/nophptags?&#why_this_is_better_than_now -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
