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

91–100 of 172 posts

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

#91

Post by rwj »

kccqzy wrote: post #77
pornel wrote: post #48

Earlier quoted context omitted.

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 m…

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

Inline reduces round trips.

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

#92

Post by shevy-java »

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 - APIs should ideally be as great as possible the moment they are introduced and shown to the public.

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

#93

Post by lloydatkinson »

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.

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

#94

Post by madeofpalk »

staticassertion wrote: post #76
Cthulhu_ wrote: post #68

Earlier quoted context omitted.

Ideally you should be able to set a global property somewhere (as a web developer) that disallows outdated APIs like `innerHTML`, but with the Big Caveat that your website will not work on browsers older than X. But maybe there's web standards for that already, backup content if a browser is considered outdated.

Doesn't using TrustedTypes basically do that? I'm not really web-y, someone please correct me if I'm off.

Yup, this is basically what TrustedTypes is for!

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

#97

Post by entuno »

jncraton wrote: post #14
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…

You are right that the concept of "safe" is nebulous, but the goal here is specifically to be XSS-safe [1]. Elements or properties that could allow scripts to execute are removed. This functionality lives in the user agent and prevents adding unsafe elements to the DOM itself, so it should be easier to get correct than a string-to-string sanitizer. The logic of "is the element currently being added to the DOM a " is…

It's certainly an improvement over people trying to homebrew their own sanitisers. But that distinction of being XSS-safe is a potentially subtle one, and could end up being dangerous if people don't carefully consider whether XSS-safe is good enough when they're handling arbitrary users input like that.

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

#98

Post by entuno »

onion2k wrote: post #86
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…

it's not at all clear which is which from the names There's setHTML and setHTMLUnsafe. That seems about as clear as you can get.

If that'd been the design from the start, then sure. But it's not at all obvious that setHTML is safe with arbitrary user input (for a given value of "safe") and innerHTML is dangerous.

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

#99

Post by lenkite »

kccqzy wrote: post #77
pornel wrote: post #48

Earlier quoted context omitted.

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 m…

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.

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

#100

Post by intrasight »

jncraton wrote: post #14
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…

You are right that the concept of "safe" is nebulous, but the goal here is specifically to be XSS-safe [1]. Elements or properties that could allow scripts to execute are removed. This functionality lives in the user agent and prevents adding unsafe elements to the DOM itself, so it should be easier to get correct than a string-to-string sanitizer. The logic of "is the element currently being added to the DOM a " is…

Also has made me nervous for years that there's been no schema against which one can validate HTML. "You want to validate? Paste your URL into the online validation tool."
Post reply on HN