Aral Balkan
I’ve never understood dangerouslySetInnerHTML. Been working on the authoring/HTML rendering in Kitten and I’ve decided on the following model:
- Anything you interpolate into your templates is escaped. So you’re protected from script injection by default. (I’m a big fan of safe by default vs. blame after the fact.)
- To include HTML, you call safelyAddHtml(untrustedHtml) in your template. That sanitises it before adding.
Think I’m happy with that.
Aral Balkan
@cjk I get that. What I don’t get is why it wasn’t a safelySetInnerHTML function to begin with :)
(With dangerouslySetInnerHTML being a private implementation detail.)
Christian Kruse
@aral the name `dangerouslySetInnerHtml` is about communication.
History has shown that when you provide tools, people w/o the knowledge to understand the consequences will use these tools. Naming it `dangerously` is a hint to the developer that what they are doing is potential dangerous.
„sanitizing“ the input reduces the attack vector, but you sanitization algorithm is much more complex than simple escaping and thus might contain bugs. So calling it dangerous still makes sense to me.
Aral Balkan
PJ Coffey
That's a very good way to think about it. In the chemical industry the concept was
Risk = f(Hazard, exposure) if your exposure control failed you got exposed to the full hazard, so you should concentrate on making processes inherently less hazardous.
You already seem to know that, but you seem like the sort to appreciate a good pseudo-equation. 😀
Aral Balkan
@Homebrewandhacking Pseudo-equations FTW :)
Fabien
@aral Hi Aral, l love the Kitten name.
if this URL (found on the project github page) is supposed to be working, well it isn’t… https://kitten.small-web.org/ (and neither is www.small-web.org, but small-web.org works)
Aral Balkan
@fabienmarry Oh, that’s live somewhere, sorry. It’s not ready yet. Currently the repository is the only live site.
Aral Balkan
@DanielMicay @dalias Good to know but my use case with Kitten is server-side rendering.
Daniel Micay
@dalias @aral This can be enabled using Content-Security-Policy: require-trusted-types-for 'script'; trusted-types 'none'. It disables the unsafe APIs (XSS sinks) like innerHTML injecting text as HTML and similar problematic approaches. Defining `trusted-types 'none'` disables non-browser-defined trusted sanitizers.
https://microsoftedge.github.io/edgevr/posts/eliminating-xss-with-trusted-types/ is a good article about it from Microsoft. We use this approach for the GrapheneOS sites, although zip library used for the web installer is incompatible.
Daniel Micay
@dalias @aral Firefox and Safari haven't implemented it yet but Mozilla has an incomplete linting tool meant to enforce the same rules:
* https://github.com/mozilla/eslint-plugin-no-unsanitized
* https://github.com/mozilla/eslint-plugin-no-unsanitized/issues/81
Nicer to have it enforced as part of Content-Security-Policy instead of as a linting tool. I can understand not wanting the complexity of non-browser-defined sanitizers. Maybe they'd be willing to implement only the 'perfect types' mode (trusted-types 'none') without it. It just rules out ugly frameworks.
Rich Felker
@aral The way I like to think about this stuff is as a type system, where HTML and text are different types that can't just be mixed haphazardly.
０７６萌ＳＮＳ is a social network, courtesy of ０７６. It runs on GNU social, version 2.0.2-beta0, available under the GNU Affero General Public License.
All ０７６萌ＳＮＳ content and data are available under the Creative Commons Attribution 3.0 license.