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

121–130 of 172 posts

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

#121

Post by lelanthran »

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.

> never allow the user to add any sort of HTML too the document.

What about when the author of the page wants to add large html fragments to the page?

Are you saying that you cannot think of a single use for this, considering how often innerHTML is being used?

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

#122

Post by iLoveOncall »

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…

You'd never want to store the processed HTML anyway, this is website building 101.

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

#123

Post by iLoveOncall »

piccirello wrote: post #66
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?

`setHTML` is meant as a replacement for `innerHTML`. In the use case you describe, you would have never wanted `innerHTML` anyway. You'd want `innerText` or `textContent`.

But that's what setHTML isn't at all a replacement for innerHTML.

You still need innerHTML when you want to inject HTML tags in the page, and you could already use innerText when you didn't want to.

Having something in between is seriously useless.

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

#124

Post by pier25 »

lloydatkinson wrote: post #93
shevy-java wrote: post #92

Well, the name SetHTML, or let's say: .set_html() Makes objectively more sense than: .inner_html() .inner_html = .set_inner_html() It is a fairly small thing, but ... really. One day someone should clean up the mess that is JavaScript. Guess it will never happen, but JavaScript has so many strange things ... I understand that this here is about protection against attacks rather than a better API design, but really -…

To be pedantic that’s the DOM API, which is exposed to JavaScript. The DOM API has always felt like, and still does, it was written by people that have never made an API.

I don't think that's pedantic. Seems like a valid objection to me.

So many issues in the client JS world originate from insufficient or bad browser APIs.

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

#125

Post by Vinnl »

yawaramin wrote: post #120
Vinnl wrote: post #20

Earlier quoted context omitted.

I kinda like the way JS evolved into a modern language, where essentially ~everyone uses a linter that e.g. prevents the use of `var`. Sure, it's technically still in the language, but it's almost never used anymore. (Assuming transpilers have stopped outputting it, which I'm not confident about.)

Actually... https://github.com/microsoft/TypeScript/issues/52924

Ah yeah, I remember that. General point still stands: in terms of the lived experience of developers, `var` is essentially deprecated.

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

#127

Post by runarberg »

lenkite wrote: post #99
kccqzy wrote: post #77

Earlier quoted context omitted.

If you just serve SVGs through tag it’ll be much safer. I never understood the appeal of inline anyways.

Inline SVG is stylable with CSS styles in the same HTML page.

Also animatible with the same context (Animation API, etc.) as the parent page, so different SVGs can influence each other’s animations.

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

#128

Post by orf »

croes wrote: post #116
orf wrote: post #108

Earlier quoted context omitted.

So we shouldn’t mark anything as unsafe then? And give no indication whatsoever? The issue isn’t that the word “safe” doesn’t appear in safe variants, it’s that “unsafe” makes your intentions clear: “I know this is unsafe, but it’s fine because of X and Y”.

Maybe we should add the word safe and consider everything else as unsafe

Like life, things should default to being safe. Unsafe, unexpected behaviours should be exception and thus require an exceptional name.

Legacy and backwards compatibility hampers this, but going forward…

Post reply on HN