Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Goodbye InnerHTML, Hello SetHTML: Stronger XSS Protection in Firefox 148

hacks.mozilla.org

Post reply on HN
Print view View original

41–50 of 172 posts

Re: Goodbye InnerHTML, Hello SetHTML: Stronger XSS Protection in Firefox 148

#41

Post by Aachen »

cogman10 wrote: post #29
Aachen wrote: post #24

So you can still inject or ... etc into your username, in the given example Preventing one bug class (script execution) is good, but this still allows arbitrary markup to the page (even CSS rules) if I'm reading the docs correctly. You could give Paypal a fresh look for anyone who opens your profile page, if they use this. Who would ever want this?

> Who would ever want this? The main case I can think of is wanting some forum functionality. Perhaps you want to allow your users to be able to write in markdown. This would provide an extra layer of protection as you could take the HTML generated from the markdown and further lock it down to only an allowed set of elements like `h1`. Just in case someone tried some of the markdown escape hatches that you didn't exp…

> This would provide an extra layer of protection

I think this might be the answer. There's no point to it by itself (either you separate data and code or you don't and let the user do anything to your page), but if you're already using a sanitiser and you can't use `textContent` because (such as with Markdown) there'll be HTML tags in the output, then this could be extra hardening. Thanks!

Re: Goodbye InnerHTML, Hello SetHTML: Stronger XSS Protection in Firefox 148

#42

Post by byproxy »

Aachen wrote: post #24

So you can still inject or ... etc into your username, in the given example Preventing one bug class (script execution) is good, but this still allows arbitrary markup to the page (even CSS rules) if I'm reading the docs correctly. You could give Paypal a fresh look for anyone who opens your profile page, if they use this. Who would ever want this?

> but this still allows arbitrary markup to the page (even CSS rules) if I'm reading the docs correctly.

If that's true, seems like it's still a security risk given what you can do with CSS these days: https://news.ycombinator.com/item?id=47132102

Re: Goodbye InnerHTML, Hello SetHTML: Stronger XSS Protection in Firefox 148

#44

Post by evilpie »

cogman10 wrote: post #26

Seems like this has a bunch of footguns. Particularly if you interact with the Sanitizer api, and particularly if you use the "remove" sanitizer api. Don't get me wrong, better than nothing, but also really really consider just using "setText" instead and never allow the user to add any sort of HTML too the document.

Using an allowlist based Sanitizer you are definitely less likely to shoot yourself in the foot, but as long as you use setHTML you can't introduce XSS at least.

Re: Goodbye InnerHTML, Hello SetHTML: Stronger XSS Protection in Firefox 148

#45

Post by tbrownaw »

croes wrote: post #23
voxic11 wrote: post #4

Earlier quoted context omitted.

The idea is you wouldn't mix innerHTML and setHTML, you would eliminate all usage of innerHTML and use the new setHTMLUnsafe if you needed the old functionality.

If I need the old functionality why not stick to innerHTML?

Because then your linter won't be able to tell you when you're done migrating the calls that can be migrated.

Re: Goodbye InnerHTML, Hello SetHTML: Stronger XSS Protection in Firefox 148

#46

Post by Aachen »

embedding-shape wrote: post #28
Aachen wrote: post #27

Earlier quoted context omitted.

> How exactly, given that setHTML sanitizes the input? The article says that the output is: Hello my name is So it keeps (non-script) html tags (and presumably also attributes) in the input. Idk how you're asking "how" since it's the default behavior Stripping HTML tags completely has always been possible with the drop-in replacement `textContent`. Making a custom configuration object for that is much more roundabout

Yes, because that's the default configuration, if you don't want that, stop using the default configuration? It's still sanitizing away the common XSS holes, hence it's a safer alternative to .innerHTML, and a more flexible alternative to .innerText

Shouldn't use innerText anyway (nonstandard, worse performance, tries to parse the HTML and gives you unexpected behavior if e.g. a style is set that makes an element invisible but still has text inside, doesn't work on all DOM nodes...)

I can see how it's a way of allowing some tags like bold and italic without needing a library or some custom parser, but I didn't understand what the point of this default could be and so why it exists (a sibling comment proposed a plausible answer: hardening on top of another solution)

> Yes, because that's the default configuration, if you don't want that, stop using the default configuration?

"don't use it if it's not what you want" is perhaps the silliest possible answer to the question "what's the use-case for this"

Re: Goodbye InnerHTML, Hello SetHTML: Stronger XSS Protection in Firefox 148

#47

Post by extraduder_ire »

voxic11 wrote: post #4
entuno wrote: post #2

This kind of thing always makes me nervous, because you end with a mix of methods where you can (supposedly) pass arbitrary user input to them and they'll safely handle it, and methods where you can't do that without introducing vulnerabilities - but it's not at all clear which is which from the names. Ideally you design that in from the state, so any dangerous functions are very clearly dangerous from the name. But…

The idea is you wouldn't mix innerHTML and setHTML, you would eliminate all usage of innerHTML and use the new setHTMLUnsafe if you needed the old functionality.

I looked up setHTMLUnsafe on MDN, and it looks like its been in every notable browser since last year.

Good idea to ship that one first, when it's easier to implement and is going to be the unsafe fallback going forward.

Re: Goodbye InnerHTML, Hello SetHTML: Stronger XSS Protection in Firefox 148

#48

Post by pornel »

snowhale wrote: post #15
entuno wrote: post #2

This kind of thing always makes me nervous, because you end with a mix of methods where you can (supposedly) pass arbitrary user input to them and they'll safely handle it, and methods where you can't do that without introducing vulnerabilities - but it's not at all clear which is which from the names. Ideally you design that in from the state, so any dangerous functions are very clearly dangerous from the name. But…

[dead]

BTW, HTML allows inline SVG with an XML-flavored syntax that interprets and differently. It's a goldmine for sanitizer escapes. There are completely bonkers syntax switching and error recovery rules that interact with parsing modes (there's even an edge case where a particular attribute value switches between HTML and XML-ish parsing rules).

Don't even try to allow inline from untrusted sources! (and then you still must sanitise any svg files you host)

Re: Goodbye InnerHTML, Hello SetHTML: Stronger XSS Protection in Firefox 148

#49

Post by jaffathecake »

entuno wrote: post #2

This kind of thing always makes me nervous, because you end with a mix of methods where you can (supposedly) pass arbitrary user input to them and they'll safely handle it, and methods where you can't do that without introducing vulnerabilities - but it's not at all clear which is which from the names. Ideally you design that in from the state, so any dangerous functions are very clearly dangerous from the name. But…

fwiw, if you serve your page with:

Content-Security-Policy: require-trusted-types-for 'script'

…then it blocks you from passing regular strings to the methods that don't sanitize.

Re: Goodbye InnerHTML, Hello SetHTML: Stronger XSS Protection in Firefox 148

#50

Post by embedding-shape »

Aachen wrote: post #46
embedding-shape wrote: post #28

Earlier quoted context omitted.

Yes, because that's the default configuration, if you don't want that, stop using the default configuration? It's still sanitizing away the common XSS holes, hence it's a safer alternative to .innerHTML, and a more flexible alternative to .innerText

Shouldn't use innerText anyway (nonstandard, worse performance, tries to parse the HTML and gives you unexpected behavior if e.g. a style is set that makes an element invisible but still has text inside, doesn't work on all DOM nodes...) I can see how it's a way of allowing some tags like bold and italic without needing a library or some custom parser, but I didn't understand what the point of this default could be a…

> Shouldn't use innerText anyway (nonstandard, worse performance, tries to parse the HTML and gives you unexpected behavior if e.g. a style is set that makes an element invisible but still has text inside, doesn't work on all DOM nodes...)

Maybe you meant .innerHTML? .innerText AFAIK doesn't try to parse HTML (why would it?), but I don't understand what you mean with nonstandard, both .innerHTML and .innerText are part of the standards, and I think they've been for a long time.

> but I didn't understand what the point of this default could be and so why it exists (a sibling comment proposed a plausible answer: hardening on top of another solution) [...] the question "what's the use-case for this"

I guess maybe third time could be the charm: it's for preventing XSS holes that are very common when people use .innerHTML

Post reply on HN