[RFC] No PHP tags

Hi Rasmus, On Wed, Feb 12, 2014 at 10:29 AM, Rasmus Lerdorf <rasmus@lerdorf.com> wrote:

I agree completely . Sorry that the RFC was hard to read. I reorganized the RFC. script() and script_once() will solve most of LFI issue. I added "Open Issue" section. I think all we have to consider is whether we allow a little inconsistency for directly called scripts or not. Regards,

Yasuo Ohgaki wrote:

I'll refer you agin to https://wiki.php.net/rfc/source_files_without_opening_tag which was cloulding my own reading of the new rfc! Tom's first paragraph is the pertinent bit ... In the past I did my best work while sleeping. Gather all the facts and go to bed ... invariably I'd wake up as I have now in the early hours of the morning with an answer. Problem these days is simply remembering enough information to work with. As we get older the 20+ years old stuff remains stubbornly stable and we forget the new stuff! That is why as you get older you will start objecting to unnecessary change ... I still hit <Ctrl><C> for copy even where the 'new' version is <Shift><Ins> :( But as usual I'm digressing ... old age. RFI is as far as I an tell simply a matter of of configuring the web server to only process .php files via PHP ? If you are allowing users to upload .PHP files onto your machine in a location they can then run them you have bigger problems than PHP. LFI is the one that will allow corrupted files containing .php tags to run if you have not taken care of them while they are being uploaded. ONLY permanently disabling embedding will guarantee that these files do not get accidentally loaded. i.e. 'changes the spirit of PHP too much' ... ---- function render_template($template, $template_vars) { ini_set('template_mode', 'on'); // Older PHP ignores include($template, $template_vars); // Or use any other method to render. ini_set('template_mode', 'off'); // Older PHP ignores } ---- Simply pushes the problem around a little and still requires that '$template' does not point at a file that contains embedded nasties? include($template.'.php', $template_vars); does the job a lot easier? Modern frameworks ... if they are well designed ... should already have addressed all of the holes that could allow tainted files to be accessed. Embedding is the essence of PHP and for many users adding a few lines of PHP to an essentially html document is all that is needed. They don't need the ton of framework code? Smarty dropped embedded PHP from their templates in S3 'because of the security risk' but all it actually did was required that the problem php code in S2 scripts was moved back into the calling PHP. It lost a LOT of flexibility and passed the buck rather than fixing the problem. It did not fix the risk at all. I don't see how this is doing any more than pushing the problem around? You still need to properly sanitise the material and if people want to do stupid things like ini_set('template_mode', 'on'); // Older PHP ignores include($_GET['template']); // Or use any other method to render. ini_set('template_mode', 'off'); // Older PHP ignores can you really protect them anyway? Anybody who codes like that when the problems are so well advertised can't be protected except by turning off 'PHP'. I'm sure many newer users would be better off simply ignoring embedded html altogether. It would make there code a lot more secure and would remove the need for tags, but is that then PHP?

On 02/13/2014 02:51 PM, Yasuo Ohgaki wrote:

Perhaps the biggest part of writing secure applications is understanding your tools and your environment. The more complicated they are, the harder it is to use them correctly. You are asking to add a brand new high-level concept to PHP by adding a distinction between a template and a non-template file. As far as PHP is concerned, everything is a "template", although we never use that term. Even a plain text file with no php tags is a template. There is no technical difference between a file containing: hello world and one containing: <?= "hello world\n"; They both compile to exactly: ECHO 'hello+world%0A' RETURN 1 So what is a template? What isn't a template? Is it a template simply because it contains a PHP tag? Or is a file not a template because it doesn't? Or is it the name of the file? What about its location? In the end, none of these things fully define a template. A template is defined by the context in which it is used. Changing this basic characteristic of PHP is a really serious change and you are going to need a much better argument than simple LFI for it to have any chance in a vote I would suspect. Striving to make PHP more secure for neophyte developers is always a worthy goal, but it needs to be done in a way that doesn't make things worse. I think this particular approach would make things worse by needlessly complicating things. -Rasmus

On Sat, 2014-02-15 at 07:28 +0900, Yasuo Ohgaki wrote:

People using the wrong feature won't be fixed by adding yet another way to open a file. johannes