Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » Re: [RFC] New operator for context-dependent escaping »

Re: [RFC] New operator for context-dependent escaping

php.internals

Unnamed Person

10 years ago
> It's not that difficult to write a static analyser that detects > instances of "<?=" not followed by "h(" or "e(" or whatever.
<?* and <?= are same for all applications, h() is user-defined. So you need to write a different analyzer for every application if you use h() or e().
> Surely the feature gets most of its value from what you *don't* need to > do - which is why I think it's bizarre that the current version doesn't > even have a built-in HTML escaper at all.
I think it's no problem to have a follow-up rfc defining some default escapers.
> It's not possible for multiple frameworks or libraries to declare > different escape handlers in your proposal, either.
not sure I get your point? public function render($template) { set_escape_handler(['SomeClass', 'methodName']); ob_start(); include $template; $content = ob_get_clean(); restore_escape_handler(); return $content; }
> You could equally say, "with <?=e()?> you have to define an e() > function". The main effort is remembering to use the right syntax, which > you have to do either way.
the thing here is that people can use <?= without e() and save coding time. Security cannot be optional, see. git clone https://github.com/phpmyadmin/phpmyadmin.git git log | grep -i xss | wc -l 206 Regards Thomas Rowan Collins wrote on 24.07.2016 18:39:

Rowan Collins

10 years ago
On 24/07/2016 18:06, Thomas Bley wrote:
>> It's not that difficult to write a static analyser that detects >> instances of "<?=" not followed by "h(" or "e(" or whatever. > <?* and <?= are same for all applications, h() is user-defined. So you need to write a different analyzer for every application if you use h() or e().
This argument is only valid if the RFC includes an implementation, not just a syntax. As currently proposed, not even the syntax would be the same for all applications, as part of it is hand-waved as up to whoever writes the escape callback.
>> Surely the feature gets most of its value from what you *don't* need to >> do - which is why I think it's bizarre that the current version doesn't >> even have a built-in HTML escaper at all. > I think it's no problem to have a follow-up rfc defining some default escapers.
In my opinion, they are central to the feature, not an optional extra.
> >> It's not possible for multiple frameworks or libraries to declare >> different escape handlers in your proposal, either. > not sure I get your point? > > public function render($template) { > set_escape_handler(['SomeClass', 'methodName']); > ob_start(); > include $template; > $content = ob_get_clean(); > restore_escape_handler(); > return $content; > }
OK, so I can dynamically redefine the same syntax to mean different things at different times, within the same application. I'm not entirely sure that's a particularly good thing.
>> You could equally say, "with <?=e()?> you have to define an e() >> function". The main effort is remembering to use the right syntax, which >> you have to do either way. > the thing here is that people can use <?= without e() and save coding time.
People can use <?= instead of <?* and save learning the difference. Lazy people will still be lazy. Yes, there's a very slight effort saved by it being shorter, but at the cost of a minimum PHP version, an extra thing to learn, etc.
> Security cannot be optional, see.
Then why is absolutely everything in the current RFC optional and configurable to the Nth degree? Regards,
-- Rowan Collins [IMSoP]

Unnamed Person

10 years ago
> Then why is absolutely everything in the current RFC optional and > configurable to the Nth degree?
It's one handler: set_escape_handler() (N=1) Currently, every framework has it's own methods for escaping. To get this together, set_escape_handler() is a good choice, similar to set_error_handler().
> OK, so I can dynamically redefine the same syntax to mean different > things at different times, within the same application. I'm not entirely > sure that's a particularly good thing.
It's the same thing with set_error_handler(), set_exception_handler(), spl_autoload_register(), error_reporting(), etc., this concept is proven to work.
> In my opinion, they are central to the feature, not an optional extra.
maybe you can join the rfc and provide the implementation? Regards Thomas Rowan Collins wrote on 24.07.2016 19:41:

Rowan Collins

10 years ago
On 24/07/2016 19:09, Thomas Bley wrote:
>> Then why is absolutely everything in the current RFC optional and >> configurable to the Nth degree? > It's one handler: set_escape_handler() (N=1) > > Currently, every framework has it's own methods for escaping. To get this together, set_escape_handler() is a good choice, similar to set_error_handler().
It's not set_escape_handler() that I'm concerned about, it's how you actually use it in the templates. At the moment, the only thing the RFC actually asserts about the escape handler is "it's a function with two arguments". Frameworks are free to write all sorts of weird shit: <?* $foo, 'html' ?> <?* 'html', $foo ?> <?* $foo, 'text/html' ?> <?* $foo, [$this, 'escaper'] ?> <?* $foo, $this ?> <?* $foo, 'js | html' ?> <?* $foo, 'js + html' ?> <?* $foo, ['js', 'html'] ?> <?* $foo, '[js, html]' ?> <?* $foo, '{js, html}' ?> <?* $foo, 'html(UTF-8)' ?> <?* $foo, 'UTF-8' ?> <?* [$foo, $bar, $baz], 'ul > li' ?> etc etc If you want to provide something that will be the same in all frameworks, then you've got to actually provide it.
>> OK, so I can dynamically redefine the same syntax to mean different >> things at different times, within the same application. I'm not entirely >> sure that's a particularly good thing. > It's the same thing with set_error_handler(), set_exception_handler(), spl_autoload_register(), error_reporting(), etc., this concept is proven to work.
OK, fair enough. I'm not sure it's really a killer feature, though. The fact that I can't easily redefine "function e()" is no more of a problem here than anywhere else in the language.
>> In my opinion, they are central to the feature, not an optional extra. > maybe you can join the rfc and provide the implementation?
The implementation I'm talking about is hardly complex, just some default arguments to htmlspecialchars(). Or that would be the case, if we didn't need to provide one escape callback to handle all possible arguments, rather than registering for a specific strategy name. Regards,
-- Rowan Collins [IMSoP]

Unnamed Person

10 years ago
> Frameworks are free to write all sorts of weird shit:
with set_escape_handler(), the "weird shit" is in one place and can be quickly verified. Now the "weird shit" is spread over all templates. Normally the problem is not fixing the frameworks, it's most work to fix code that is using the frameworks in a wrong way. Regards Thomas Rowan Collins wrote on 24.07.2016 20:29: