> > > "allow_url_include" and "template_mode" is similar to me. > > allow_url_include: enable only when url include is needed. > template_mode: enable only when template mode is needed. > > allow_url_include prevents RFI which may result in critical security > incident. > template_mode prevents LFI which may result in critical security incident. > > Note: template_mode=off is script only mode. On is current behavior. > > I just glanced over the RFC. See my comments below: "LFI/RFI is fatal security error. Currently, LFI prevention is upto programmers and framework authors/system admins do not have feasible way to prevent LFI" what about open_basedir?
"Current PHP is weak to script injections compare to other languages such as Ruby/Perl/Phthon/Lua/etc." would be nice listing what does those languages do better in thise regard. AFAIK ruby allows you to include arbitrary files, and the rails security guides even mention the file upload vulnerability: http://guides.rubyonrails.org/security.html#executable-code-in-file-uploads perl also have require, Python has import, which is maybe a little bit harder to misuse, lua has both dofile and require. it would be nice explaining what do you mean by php being week compared to those languages. "PHP script inclusion detection may be done for data files. However, it's not a simple task." as I mentioned before, I don't think that it is the good way to try to detect the injected code in the data files: one should know beforehand that whether is the uploaded file is meant to be a data file or a script file, and act accordingly. "Almost all applications are not checking these and it would be impossible to make developers do a proper validation." these kind of filtering techniques are error prone. "Disabling embed(template) mode is simple solution for this issue." one can still upload valid embed files and if the LFI is present, execute those. so your solution would only improve this problem, if an LFI vulnerability is present or the uploaded files are publically accessible and not excluded from the execution and the file uploads otherwise properly type validated and the developer choses to be compatible with the template_mode off and disables it(as the default would be on). I think that it would be really hard to adopt. Framework developers are trying to support the widest audience, and supporting both template_mode On and Off will be a major PITA imo. and until they do, the average developer can't be expected to make his choice of framework compatible with template_mode off, so he/she won't use it. I think it would require far less work to find and fix the LFIs and properly configure the webserver than rewriting your whole application (including your libraries). IDEs would be in the same spot, they can't tell you that whether or not your file is missing the opening tags without looking into your php.ini/apache vhost/.htaccess config. it can be either fine or a bug, depending on the value of template_mode as Stas pointed out, if you migrate your codebase which depends on template_mode = Off, and you forgot to change the default php.ini (yeah, you should notice this before going live, but we are talking about the people having LFI and other vulns...) then your files will be served by your webserver as is. which itself can compromise your system. "With this RFC, the only allowed PHP tag under non embed mode is ”<?php”." oh, isn't that contradicting "This RFC proposes removal of PHP tags (<?php and so forth) from the PHP script by php.ini or CLI option flags." and "Not a few programmers may once have been bothered to put a PHP tag at the top of every PHP script that only contains classes and functions. In short, PHP tags are just ancient." although it would lessen the BC/incompatibility problems mentioned above. In general I'm -1 on this RFC, I think that the people who are vulnerable wouldn't use it, and there are better alternatives for the described problems than the introduction of template_mode. this would add an additional level of complexity and would make it harder to write portable code. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
