Hacker News Reader

Comment by lucideer | Hacker News Reader

This is a bad article, but it's a great example of why tech like Electron have succeeded.

This article is a long boring rant with zero insights, in which the author never thinks to ask why...

> Why in the world has this idiotic trend of abstracting everything away by layers upon layers of complexity gained such a strong foothold in the industry? Has everyone except the "unix greybeards" gone mad!?

... ok he does use the word "why" once but only in a rhetorical question. It's never asked honestly.

Electron solves problems that "unix greybeards" have been loudly and wilfully sticking their heads in the sand about for decades. Yes, it solves them badly, but that's a lot better than not solving them at all.

... he also complains briefly about PHP templating libraries which tells me he's never had to mitigate XSS vulnerabilities in large PHP applications.

View on HN

> he's never had to mitigate XSS vulnerabilities in large PHP applications.

You can do this with <?= e(<expression-to-escape>) ?>, where e is a function that escapes strings.

Is this more work than writing {{ <expression-to-escape> }}? I guess, but this is what your template library is doing under the hood anyway.

The question is not how mitigate vulnerability. Every vulnerability is trivially easy to mitigate.

The question is whether it's easy to write vulnerable code.

For PHP it's easy and implicit:

    <div><?= some_expression ?></div>

For React it's hard and explicit:

    <div dangerouslySetInnerHTML={{ __html: someExpression }} />

While I agree with the overall point, these are different environments.

React normally operates in a DOM. It's templates are translated into javascript, and that javascript manipulates the DOM. PHP templates are just outputting strings.

ReactDOMServer also outputs strings; it just works with context-aware objects during template processing.

The point here is that PHP templates work with strings as a design choice: there's nothing about PHP as a language that's preventing you from taking a similarly context-aware template-processing approach.

I specifically said "large PHP applications" instead of just "PHP applications" because the difficulty is not in writing, it's in auditing and enforcing.

Even within templating libraries there are different levels of advancement around context-awareness: e.g. <div onclick="{{ val }}"> is still dangerous in languages like Twig, and is similarly challenging to audit. Alternatives like Latte mitigate this but even Twig is still a large degree easier to work with than vanilla PHP.

"Large PHP applications" doesn't immediately express to me that you combine styles, scripts, and markup in your templates and have a need for automated context-aware escaping.

It doesn't need to.

"Large PHP application" just means "at scale", in terms of LoC, and - most likely - contributors. Which means (a) potentially anything may be combined in templates by somebody at some point without careful manual code-review, which is difficult to audit at scale, and (b) there are a larger number of files to audit, likely with a degree of complexity to their overall structure, which further adds to that difficulty.

You can overcome this using a linter that doesn't allow expressions in those contexts, no?

Reply on news.ycombinator.com