Hacker News Reader

Comment by franciscop | Hacker News Reader

I tried making something like this (JSX with Template Literals) few times, they are languishing in unfinished JSFiddles. The main issue was making it XSS-safe by default, which as I see this hasn't achieved at all!

XSS demo 1: https://jsfiddle.net/hegLkz4s/2/

XSS demo 2: https://jsfiddle.net/hegLkz4s/4/

So, please do not use this, use React or similar well-tested libraries instead. There might be a way to make something like this that is XSS-safe by default (I got pretty close), but brutal.js does not seem to be it.

View on HN

Demo 2 seems to be a problem with jsfiddle:

https://jsfiddle.net/hegLkz4s/22/

It's also already been reported:

https://github.com/jsfiddle/jsfiddle-issues/issues/963

You're right about there being an XSS vulnerability here though. But you can fix it pretty easily by escaping the HTML:

https://jsfiddle.net/hegLkz4s/17/

Merged your PR!

What is the attack vector?

There are a number of HTML attributes and properties that can result in redirects, HTTP requests, and evaluation of arbitrary code.

If the developer uses databinding with untrusted input into any of these attributes or properties, their site may be exploitable. A databinding engine can do some things to protect against this. One way of handling this is to treat strings as untrusted by default, and require explicit wrapping types for trusted content, e.g. https://google.github.io/closure-library/api/goog.html.SafeU...

lit-html, a similar HTML templating with template literals library, achieves /mostly/ XSS-safe by default by never interpolating dynamic data before parsing, but interpolating after parsing and DOM construction and then using textContent, not innerHTML.

That means that user-provided text can't inject markup into the page.

There are still a number of sensitive attributes that we want to be automatically sanitized for you, like src/href/on*, but we have the hooks needed for that and just need to add the contextual sanitizer.

Does it throw if a template returns a string? While it's a cool feature to be able to do this, it's also quite dangerous (specially when dealing with beginners for this library) to have these two behaving almost the same but one being safe and the other not:

    // Safe version
    const header = title => html`<h1>${title}</h1>`;

    // Unsafe version, but it "works" as expected
    const header = title => `<h1>${title}</h1>`;

It doesn't throw, the unsafe version is just escaped by the browser:

Let's consider a container where a function like `header` would be used:

    const page = (title, body) => html`
      ${header(title)}
      <p>${body}</p>
    `;

If you use the safe version, you might get:

    <h1>Foo</h1>
    <p>Bar</p>

but if you use the unsafe version, you'd get:

    &lt;h1&gt;Foo&lt;/h1&gt;
    <p>Bar</p>

See a demo here: https://stackblitz.com/edit/lit-html-escaping?file=index.js

Ah cool, that works as well from a security point of view. I slightly prefer throwing, but that is highly opinionated.

Reply on news.ycombinator.com