Re: [RFC] [VOTE] is_literal
| From: | Craig Francis | 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