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

141–150 of 172 posts

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

#141

Post by Dylan16807 »

cxr wrote: post #134
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. Ideally you design that in from the [start] It was, and there is: setting elementNode.textContent is safe for untrusted inputs, and setting elementNode.innerHTML is unsafe for untrusted inputs. The former will escape everything, and the latter won't escape anything. You are right that these "sanitizers" are fundamentally confused: > "HTML sanitization" is never g…

> There's no getting around knowing whether or any arbitrary string is legitimate markup from a trusted source or some untrusted input that needs to be treated like text. This is a hard requirement.

It is not a hard requirement that untrusted input is "treated like text". And this API lets you customize exactly what tags/attributes are allowed in the untrusted input. That's way better than telling everyone to write their own; it's not trivial.

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

#142

Post by cxr »

Dylan16807 wrote: post #141
cxr wrote: post #134

Earlier quoted context omitted.

> it's not at all clear which is which from the names. Ideally you design that in from the [start] It was, and there is: setting elementNode.textContent is safe for untrusted inputs, and setting elementNode.innerHTML is unsafe for untrusted inputs. The former will escape everything, and the latter won't escape anything. You are right that these "sanitizers" are fundamentally confused: > "HTML sanitization" is never g…

> There's no getting around knowing whether or any arbitrary string is legitimate markup from a trusted source or some untrusted input that needs to be treated like text. This is a hard requirement. It is not a hard requirement that untrusted input is "treated like text". And this API lets you customize exactly what tags/attributes are allowed in the untrusted input. That's way better than telling everyone to write t…

[flagged]

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

#143

Post by Dylan16807 »

intrasight wrote: post #100
jncraton wrote: post #14

Earlier quoted context omitted.

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

This help? https://github.com/validator/validator

But for html snippets you can pretty much just check that tags follow a couple simple rules between and that they're closed or not closed correctly.

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

#144

Post by Dylan16807 »

iLoveOncall wrote: post #123
piccirello wrote: post #66

Earlier quoted context omitted.

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

> You still need innerHTML when you want to inject HTML tags in the page

What makes you say this?

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

#145

Post by Legend2440 »

dvh wrote: post #112

Kids in the '90s: SQL("select * from user where name = " + name); Kids in the '20s: div.innerHTML = "Hello " + user.name;

Kids in the '30s:

  "Summarize this email:  " + email.contents
Prompt injection is just the same problem on a new technology. We didn't learn anything from the 90s.

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

#146

Post by Dylan16807 »

cxr wrote: post #142
Dylan16807 wrote: post #141

Earlier quoted context omitted.

> There's no getting around knowing whether or any arbitrary string is legitimate markup from a trusted source or some untrusted input that needs to be treated like text. This is a hard requirement. It is not a hard requirement that untrusted input is "treated like text". And this API lets you customize exactly what tags/attributes are allowed in the untrusted input. That's way better than telling everyone to write t…

[flagged]

I don't see how I differed from what you said? You divided strings going into HTML into two categories, where one category uses textContent and the other category uses innerHTML. My point is to disagree with those categories, not whatever subtle thing you're taking issue with.

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

#147

Post by cxr »

Dylan16807 wrote: post #146
cxr wrote: post #142

Earlier quoted context omitted.

[flagged]

I don't see how I differed from what you said? You divided strings going into HTML into two categories, where one category uses textContent and the other category uses innerHTML. My point is to disagree with those categories, not whatever subtle thing you're taking issue with.

[flagged]

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

#148

Post by intrasight »

Dylan16807 wrote: post #143
intrasight wrote: post #100

Earlier quoted context omitted.

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

This help? https://github.com/validator/validator But for html snippets you can pretty much just check that tags follow a couple simple rules between and that they're closed or not closed correctly.

That app does look helpful!

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

#149

Post by Dylan16807 »

cxr wrote: post #147
Dylan16807 wrote: post #146

Earlier quoted context omitted.

I don't see how I differed from what you said? You divided strings going into HTML into two categories, where one category uses textContent and the other category uses innerHTML. My point is to disagree with those categories, not whatever subtle thing you're taking issue with.

[flagged]

This is a totally different kind of statement. You're not dividing tax returns into two categories and then saying what to do with each category.

Those claims are different but not in a way that analogizes to the HTML conversation.

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

#150

Post by cxr »

Dylan16807 wrote: post #149
cxr wrote: post #147

Earlier quoted context omitted.

[flagged]

This is a totally different kind of statement. You're not dividing tax returns into two categories and then saying what to do with each category. Those claims are different but not in a way that analogizes to the HTML conversation.

I'd say I'm interested in hearing how you reason that knowing whether you need to pay at least $1000 in unpaid taxes to the IRS doesn't put you in one bucket or another, but I'm not.
Post reply on HN