Re: RFC about automatic template escaping

From: Date: Tue, 22 Mar 2016 12:24:46 +0000
Subject: Re: RFC about automatic template escaping
References: 1 2 3  Groups: php.internals 
Request: Send a blank email to internals+get-91839@lists.php.net to get a copy of this message
On Mon, 21 Mar 2016 07:35:46 +0100, Daniel Beardsley <daniel@ifixit.com> wrote:
Issue is "Escaping is done on a specific context". I understand your proposal is focused on HTML escaping. However, setting names like __auto_escape_exempt_class is not good choice. It has to be __auto_html_escape_exempt_class at least because it is for HTML escaping.
Yes, the ini settings have poor names and can totally be changed.
In addition, HTML consists of multiple contexts - HTML context that requires HTML escape - URI context that requires URI escape - JavaScript context, embedded JavaScript strings for example , that requires JavaScript string escape, etc. e.g. http://blog.ohgaki.net/javascript-string-escape (Sorry. It's my blog and written in Japanese. You may try translation service or you should be able to understand PHP code at least) - CSS context that requires CSS escape. e.g. https://developer.mozilla.org/ja/docs/Web/API/CSS/escape - And so on
You are right. Though not all those problems are serious: * HTML attributes: Use ENT_QUOTES so that content is escaped well enough for use in quoted attributes (still need quotes though) * URI escaping: Does anyone really use <?= ?> or echo when generating a uri? * Javascript: Good point, though I would say it's fairly rare to create javascript code using a php template with variables. The most we ever do in our app is <?= json_encode($someArray) ?> * Eveything else: I think the better solution here is to simply let the user control this. Provide an ini setting that allows a custom output function to be set so the user could control what happens to unsafe strings and what the exemptions are. I'm considering doing this. This was html-only at the beginning because we only created this for html templates and were able to call the internal php functions directly, ginving us nearly no performance penalty.
Dealing HTML context only would be problematic even if it works for many cases. Escaping must be done depends on context. Multiple contexts may apply also. HTML context only escaping would not work well.. Applying proper escapes to variables in HTML is very complex task.. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net
The escape context could be detected (e.g. Latte template engine supports context-aware escaping for years – https://latte.nette.org/en/#toc-context-aware-escaping) but the logic is quite complex for it to be included in PHP core. Also relying on ini setting is evil as it may break existing libraries. You would need to introduce a different way to manage the setting, e.g. introduce new language construct require_template which would turn this behavior on for a single included file or new declare(template_mode=1) which you would need to write at the beginning of each template. Regards, Jan Tvrdik

« previous php.internals (#91839) next »