On 06/20/2016 10:24 AM, Rasmus Schultz wrote:
<ul>
<?php foreach ( $things as $thing ) { ?>
<li><a href="/things/<?= $thing['name'] ?>" onclick="show_popup('<?=
$thing['name'] ?>');"><?= $thing['name'] ?></a>
<?php } ?>
</ul>
There are three different escape mechanism needed there; if there is a
shorthand for one, do you think it will be more likely or less that people
will get the other two right?
I have to agree with that - assigning special syntax to one kind of
escape-function gives that function an elevated status, which could
easily encourage neglect and oversight.
I do wish that we had an obvious, consistently-named set of
web-related escape/encode functions for use in plain PHP templates,
like html(), attr(), js(), etc... having to type and read
htmlspecialchars() and json_encode() while you're trying to visually
parse a template is really inconvenient.
That's all it is though, inconvenience. Nice to have, not must have.
I'd be much more interested in a general solution to the problem of
being unable to (or at least strongly demotivated from) using actual
namespaced functions in this and many other cases - that's a missing
feature and a more general problem, whereas in my opinion an operator
or shorter function-names are just a work-around...
(and please, nobody say "use a template engine" - I *am* using a
template engine, it's called PHP!)
In many of the PHP template engines, there are multiple "filters"
available with a specific syntax, and a way to add more. You have to
specify which one you want, because only you know the context.
Twig (and possibly others?) lets you set a default escaper that can be
overridden case by case as needed, including by a "none" option.
Rather than try to make print statements themselves into a more secure
template layer (Sorry, Rasmus, that ship has long since sailed, even
Drupal gave up on PHPTemplate), perhaps it would be more useful to look
at the needs of the various template engines (Twig, Smarty, Blade, etc.)
and see what the language can/should do to make it easier for those
engines to be made secure. That same underlying tooling, then, can be
exposed in a way that those still using PHP itself as a template engine
can leverage it more easily.
I'm not 100% certain what that would look like. My initial thought
(which is potentially a terrible idea), is some sort of callable
registration, akin to stream wrappers or autoloaders, where you could do
something vaguely like this:
register_escaper('html', function($var) { return htmlentities($var,
ENT_QUOTES | ENT_HTML5); });
register_escaper('html_attrib', function($var) { ... });
register_escaper('raw', function($var) { return $var;});
set_default_escaper('html'); // I dislike a global flag like this, but
it works for this demonstration.
<?php
print $foo; // no escaping, because BC.
printe $foo; // Run through html escaper
printe($foo, 'html_attrib'); // Run through html_attrib escaper
?>
<?= $foo; ?> // No escaping
<?~ $foo ?> // Run through html escaper
<?~html_attrib $foo ?> // Run through html_attrib escaper
And then Twig, Smarty, etc. can also leverage the registered escapers,
and add their own as appropriate.
That's off-the-cuff syntax that may be terrible, but the goal here is to
better enable template engines (whether thick ones like Twig or thin
ones like *.view.php) to do security better, rather than trying to Solve
It For All The Things(tm), which for security is a very dangerous
dead-end approach.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
