Hi! > - require/include only includes ".php" ".phar" by default.
This is not true. As I repeatedly point out, your change only requires that the string passed to include would end in .php, but string passed to include and filename on filesystem are very different things, they do not have to be the same at all! > - move_uplaoded_file() only move files other than ".php", ".phar" > extension by default. > > This makes "script inclusion" attack much harder. In fact, this RFC > makes almost > impossible attackers to take advantage of PHP's embed everything nature. I am at loss how you can claim it is "impossible" after I just demonstrated how it is possible. > For users do not need these protections, they can simply add one liner. > > ini_set('zend.script_extensions', ''); > > This piece of code is executed for all PHP version without any errors. You sincerely do not understand why breaking all code that uses non-php extensions is a problem and that editing existing production code's entry points is by no way "simple"? That finding all extensions that may be used for files in a complex software is very far from "simple"? > Unlike previous RFC, this RFC patch does not care "contents" of file, but > only cares file "extensions". However, it works well as described before. It doesn't work well - in fact, it does not work at all, as I just demonstrated, exactly because extension of the actual file and what you're checking are different things. > Even with this RFC, users can shoot their own foot and PHP is much easier > to do it wrong compare to other languages. These platitudes do not change the simple fact that your RFC does not do what it claims to do, security-wise. > However, if users use new PHP by default setting, PHP is as safe as > other languages against script inclusion/upload attacks. Since we have > move_uploaded_file() protection, PHP becomes safer than others. No, it does not become safer, because if you have code that allows script inclusion injection (and if you do, it's your fault, not PHP's) it is trivial to exploit it even with this RFC. > - require/include cannot load script other than ".php"/".phar". As I showed, this is not true. I am kind of tired of repeating the same thing again and again and being completely ignored, so unless there's some new argument I'll stop repeating myself now. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php