Live data from Hacker News

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

hacks.mozilla.org

61–70 of 172 posts

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

#61
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 want to be raw HTML.

[1]: https://www.rfc-editor.org/rfc/rfc2119

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

#62
post #56

Earlier quoted context omitted.

Injecting markup into someone else's website isn't what I'd call too strict a default configuration If you mean to convey that it's possible to configure it to filter properly, let me introduce you to `textContent` which is older than Firefox (I'm struggling to find a date it's so old)

That's the whole point of the setHTML. How would I set a header level using textContent?

The traditional way: separating data and code

    document.createElement("h1").textContent = `Hello, ${username}!`
If you allow in the setHTML configuration or use the default, users with the tag in their username also always get it rendered as markup

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

#63
post #62

Earlier quoted context omitted.

That's the whole point of the setHTML. How would I set a header level using textContent?

The traditional way: separating data and code document.createElement("h1").textContent = `Hello, ${username}!` If you allow in the setHTML configuration or use the default, users with the tag in their username also always get it rendered as markup

Which is why you only use it where you want to allow some kind of html..?

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

#64
post #42
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

You can use selectors to gain some information about things like input fields, e.g. https://www.invicti.com/blog/web-security/private-data-stole...

Or I guess you could completely restyle and change the text of UI elements so it looks like the user is doing one thing when they're actually doing something completely different like sending you money

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

#66
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`.

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

#67
post #61
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…

i think the use case for setHTML is for user content that contains rich text and to display that safely. so this is not an alternative for escaping text or inserting text into the DOM but rather a method for displaying rich text. for example maybe you have an editor that produces em, and strong tags so now you can just whitelist those tags and use setHTML to safely put that rich text into the DOM without worrying about all the possible HTML parsing edge cases.

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

#68
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…

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.

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

#69
post #13
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.

> you would eliminate all usage of innerHTML The mythical refactor where all deprecated code is replaced with modern code. I'm not sure it has ever happened. I don't have an alternative of course, adding new methods while keeping the old ones is the only way to edit an append-only standard like the web.

Nobody's talking about old code here.

Having an alternative to innerHTML means you can ban it from new code through linting.

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

#70
post #38
post #23

Earlier quoted context omitted.

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

because the "unsafe" suffix conveys information to the reader, whereas `innherHTML` does not?

Any potential reader should be familiar with innerHTML.
Post reply on HN