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

101–110 of 172 posts

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

#101

Post by evilpie »

jerf wrote: post #61
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?

If I'm reading this right, .setHTML(" Hello ", new Sanitizer({})) will strip all elements out. That's not too difficult. Plus this is defense-in-depth. Backends will still need to sanitize usernames on some standard anyhow (there's not a lot of systems out there that should take arbitrary Unicode input as usernames), and backends SHOULD (in the RFC sense [1]) still HTML-escape anything they output that they don't wan…

You aren't reading it right.

  new Sanitizer({})
This Sanitizer will allow everything by default, but setHTML will still block elements/attributes that can lead to XSS.

You might want something like:

  new Sanitizer({ replaceWithChildrenElements: ["h1"], elements: [], attributes: [] })
This will replace elements with their children (i.e. text in this case), but disallow all other elements and attributes.

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

#102

Post by GalaxyNova »

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.

It's worse than nothing, since inevitably people will use this thinking it's 100% safe when it's not.

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

#103

Post by HWR_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…

That's why I only allow user input of alphanumeric ascii characters. No need to worry about sanitation then, and you can just remove all the characters that don't match.

(It's a joke, but it is also 100% XSS, SQL injection, etc. safe and future proof)

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

#104

Post by onion2k »

hahn-kev wrote: post #88
onion2k wrote: post #86

Earlier quoted context omitted.

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.

But you can use InnerHTML to set HTML and that's not safe.

At this point that API has been around for decades and is probably impossible to deprecate without breaking fairly large amounts of the web. The only option is to introduce a new and better API, and maybe eventually have the browser throw out console warnings if a page still uses the old innerHTML API. I doubt any browser vendor will be gung ho enough to actually remove it for a very long time.

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

#105

Post by dogtimeimmortal »

Title was a bit rage-baity. And I think you can already do sanitation by writing a function to check input before passing it to innerHTML?

This really just seems like another attempt at reinventing the wheel. Somewhat related, I find it ironic how i cannot browse hacks.mozilla.org in my old version of firefox("Browser not supported"). Also, developer.mozilla.org loads mangled to various degrees in current versions of palemoon, basilisk, and seamonkey

It's like there is some sort of "browser cartel" trying to screw up The Web.

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

#106

Post by croes »

orf wrote: post #85
goatlover wrote: post #70

Earlier quoted context omitted.

Any potential reader should be familiar with innerHTML.

yes, and bugs shouldn't exist because everyone should be familiar with everything.

But if some are marked unsafe and others are not it gives a false sense of security if something is not marked unsafe.

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

#108

Post by orf »

croes wrote: post #106
orf wrote: post #85

Earlier quoted context omitted.

yes, and bugs shouldn't exist because everyone should be familiar with everything.

But if some are marked unsafe and others are not it gives a false sense of security if something is not marked unsafe.

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”.

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

#109

Post by Retr0id »

dogtimeimmortal wrote: post #105

Title was a bit rage-baity. And I think you can already do sanitation by writing a function to check input before passing it to innerHTML? This really just seems like another attempt at reinventing the wheel. Somewhat related, I find it ironic how i cannot browse hacks.mozilla.org in my old version of firefox("Browser not supported"). Also, developer.mozilla.org loads mangled to various degrees in current versions of…

> you can already do sanitation by writing a function to check input before passing it to innerHTML

This is like saying C is memory safe as long as your code doesn't have any bugs.

More saliently, it does not consider parser differentials.

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

#110

Post by chrisweekly »

Aachen wrote: post #32
josefx wrote: post #19

Earlier quoted context omitted.

Wouldn't AI be trained on data using innerHTML?

My experience is that they somehow print quite modern code despite things like ES6 being too new to be standard knowledge even for me and I'm not even middle-aged yet Maybe the last 10 years saw so much more modern code than the last cumulative 40+ years of coding and so modern code is statistically more likely to be output? Or maybe they assign higher weights to more recent commits/sources during training? Not sure…

> "ES6 being too new to be standard knowledge"

Huh? It's been a decade.

Post reply on HN