Goodbye innerHTML, Hello setHTML: Stronger XSS Protection in Firefox 148

Yeah. Here is the current sanitizer I use for semi-trusted inputs:

export default function sanitizeText(text) {
  let el = document.createElement("div");
  el.innerText = text;
  text = el.innerHTML;
  text = text
    .replace(/&lt;b&gt;/g, "<b>")
    .replace(/&lt;\/b&gt;/g, "</b>")
    .replace(/&lt;i&gt;/g, "<i>")
    .replace(/&lt;\/i&gt;/g, "</i>");
  return text;
}

It makes everything into text and switches just <b> and <i> tags back to HTML. I guess I could support <strong> and <em> too. If it allowed classes or attributes or required balancing, it would be a lot more complex.

Sorry for being flippant, but what you're telling us is that many things use HTML sanitizers, only they're usually in the backend.

I'd argue you should never handle the cleaning on the server. A parser you use on your server and the parser of the user's browser will probably disagree

If you’re writing some app that has comments from users… you actually probably don’t need it, because you handle the processing and cleaning on the server, so the client is actually receiving trusted HTML. (There are designs that can reasonably want a sanitiser, but it’s less likely, and most of the time probably inferior.)

I would never treat attacker controlled content without sanitizing at both stages. Are you SURE that you sanitized all inputs and that some intern didn't forget to wire a customer data importer up correctly? Do you re-sanitize all database entries whenever you update the sanitizer? Having the browser itself do the checking means that it will get updated to cover new features as they are introduced. Even then, I would sandbox comments in an iFrame.

This is predominantly nice for vanilla JS and maybe if your favorite framework adopts it (tell your framework devs you want safe html insertion!).

The Sanitizer is also a good stepping stone to figure out what "safe by default" could look like for an opt-in document setting.

When you're fetching remote content that has inline HTML and you want to display that safely. For me this happens with ActivityPub objects, which have HTML for content.

When you can't control the backend.

Sometimes you're pulling data from a third party and you need to display it in your client. Sure, it's not a frequent use case, and often you can simply make a proxy backend for this, but you don't often have the possibility - or resources - to do it.

So you do this on the client.

Another thing is if you expect the user to be copy-pasting potentially untrusted data.

E.g. you're a bank website. You have a transaction where the client copied payment data from the email they got. Before they confirm it, you display the entire transaction once more for the user to doublecheck.

So if they were copying data from a phishing email, now they pasted a script that's running on your domain (with your js-root) and can read your cookie data, and send it to their masters. Probably not a big deal by itself. But read and white hat report of how shit got broken into, and you'll see that it's very often a lot of small steps like this, not one big glaring security hole.

So to prevent it, you have to sanitize that description field before you display it.

This can be relevant for any data input site, really.

Side benefits of this specific thing is that is you're doing it anyway, then you avoid the double parking. Once by your js sanitizer and the second time by the inner html parser.

And instead of pulling another npm dependency into your client, you can use this fancy new html standard. Plus it's native so you get speed. Not that it's gonna get noticed by one user, but we all always complain how JavaScript crap is slowing down everything, so now this means less build time, less download and parsing time by the browser, etc etc.

In global, we waste less CPU cycles so we saved one extra flower or snail or something.

You need to treat all customer data as attacker controlled content. You can't trust a sanitizer checking at the back-end to do the job right, because those sanitizers are decoupled from the browser that is running your code now. This is one reason why mysql_escape_string was so bad.

So anytime you don't control a piece content, the best pattern is to have the whatever is going to parse and manipulate that content (browser, database, etc) sanitize it first.

You're not wrong, see eg https://lobste.rs/c/s0vb9l

Right now, you can use Trusted Types to say "no unsafe HTML parsing at all" and disallow innerHTML through eslint. Then you won't accidentally write unsafe code (thanks linter) and the browser will enforce that unsafe code doesn't run (thanks Trusted Types).

People at Jun Kokatsu, formerly of Microsoft Edge, did something similar by going all-in on React (safe HTML insertion unless you do the dangerouslySetHTML) and enforcing that no unsafe code runs (with Trusted Type)

setHTML is in fact sanitizing a tree. I paid attention in my langsec classes.

This is a prevention mechanism, because it ensures that harmful content will not enter your html document, not a mitigation. CSP is a mitigation because it assumes untrusted content is already within your document.

But maybe we are talking past each other, if that’s the case I would love to read a more detailed comment or a direct email :-)

I think there's plenty in the DOM API about working directly with Element and Fragments and Document trees. Since those APIs don't really have a way to shake the tree and remove potentially malicious nodes, I think this is a decent option.