is there any situation where innerHTML would be preferable? I could suppose it might be more performant and so if you were constructing something that was not open to XSS it might theoretically be better (with the usual caveat that people always make mistakes about this kind of thing)
Goodbye InnerHTML, Hello SetHTML: Stronger XSS Protection in Firefox 148
81–90 of 172 posts
Re: Goodbye InnerHTML, Hello SetHTML: Stronger XSS Protection in Firefox 148
#82Earlier quoted context omitted.
When the condition for when you want to replace is hard to properly specify, AI shines for such find and replaces.
This one is literally matching "innerHTML = X" and setting "setHTML(X)" instead. Not some complex data format transformation But I can see what you mean, even if then it would still be better for it to print the code that does what you want (uses a few Wh) than doing the actual transformation itself (prone to mistakes, injection attacks, and uses however many tokens your input data is)
That can break the site if you do the find and replace blindly. The goal here is to do the refactor without breaking the site.
Re: Goodbye InnerHTML, Hello SetHTML: Stronger XSS Protection in Firefox 148
#83naming the old behavior setHTMLUnsafe is what did it for me. security features that require developers to opt in don't work. making the unsafe path feel unsafe does.
Re: Goodbye InnerHTML, Hello SetHTML: Stronger XSS Protection in Firefox 148
#84Earlier 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.
If I need the old functionality why not stick to innerHTML?
Because sooner or later it'll be removed.
Re: Goodbye InnerHTML, Hello SetHTML: Stronger XSS Protection in Firefox 148
#85Re: Goodbye InnerHTML, Hello SetHTML: Stronger XSS Protection in Firefox 148
#86This 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.
Re: Goodbye InnerHTML, Hello SetHTML: Stronger XSS Protection in Firefox 148
#87Earlier 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.
I looked up setHTMLUnsafe on MDN, and it looks like its been in every notable browser since last year. Good idea to ship that one first, when it's easier to implement and is going to be the unsafe fallback going forward.
I looked up setHTMLUnsafe on MDN, and it looks like its been in every notable browser since last year.
Oddly though, the Sanitizer API that it's built on doesn't appear to be in Safari. https://developer.mozilla.org/en-US/docs/Web/API/Sanitizer
Re: Goodbye InnerHTML, Hello SetHTML: Stronger XSS Protection in Firefox 148
#88This 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.
But you can use InnerHTML to set HTML and that's not safe.
Re: Goodbye InnerHTML, Hello SetHTML: Stronger XSS Protection in Firefox 148
#89So 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?
> So you can still inject or
... etc into your username
... etc into your username
Are we taking out all the fun of the web? I absolutely loved the names people had in the early days of Facebook, it was all harmless fun.
If injection of frontend code takes down your backend, your backend sucks, fix it.
Re: Goodbye InnerHTML, Hello SetHTML: Stronger XSS Protection in Firefox 148
#90Earlier 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 is 11 years old. It's not that new.