Re: [RFC] [VOTE] is_literal

From: Date: Tue, 14 Sep 2021 14:50:27 +0000
Subject: Re: [RFC] [VOTE] is_literal
References: 1 2 3 4  Groups: php.internals 
Request: Send a blank email to internals+get-116042@lists.php.net to get a copy of this message
On Wed, 8 Sept 2021 at 07:33, Claude Pache <claude.pache@gmail.com> wrote: > We all want to protect from injection vulnerability, but I think there are > better way than is_literal. > > One way is to use templates, an area where PHP is ironically lagging > behind. I suggest looking at JS tagged templates: > https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals#tagged_templates Hi Claude, Posting on-list, as I've not had a reply (was confirming I've not missed anything). I have looked at JavaScript Tagged Templates before, and while they could be made to work (ish), I don't believe they are better than the is_literal() proposal to protect against Injection Vulnerabilities: 1) It would require developers and libraries to re-write all of their existing code to use Tagged Templates. 2) If we copied JavaScript, the methods/functions can still be called incorrectly: function template(html, ...values) { > console.log(html, values); > } > template<p>Hi ${name}<p>; > template([<p>Hi ${name}<p>]); // Wrong > template(['<p>Hi ', name, '<p>']); // Wrong PHP could provide a way for Libraries to check the developer has used a Tagged Template, but that's basically what the is_literal() proposal does. With JavaScript, this is why isTemplateObject() is being developed, and Trusted Types might get fromLiteral(). 3) Libraries would not be able to use Tagged Templates and easily support older versions of PHP. 4) The backtick character is already used for shell_exec() like functionality. Craig

« previous php.internals (#116042) next »