8 ms·
I tried making something like this (JSX with Template Literals) few times, they are languishing in unfinished JSFiddles. The main issue was making it XSS-safe b
by franciscop 8y ago
I tried making something like this (JSX with Template Literals) few times, they are languishing in unfinished JSFiddles. The main issue was making it XSS-safe by default, which as I see this hasn't achieved at all!
XSS demo 1: https://jsfiddle.net/hegLkz4s/2/ https://jsfiddle.net/hegLkz4s/2/
XSS demo 2: https://jsfiddle.net/hegLkz4s/4/ https://jsfiddle.net/hegLkz4s/4/
So, please do not use this, use React or similar well-tested libraries instead. There might be a way to make something like this that is XSS-safe by default (I got pretty close), but brutal.js does not seem to be it.
- dothis 8y agoWhat is the attack vector?
- 11235813213455 8y agoXSS, can't you read?
- rictic 8y agoThere are a number of HTML attributes and properties that can result in redirects, HTTP requests, and evaluation of arbitrary code. If the developer uses databinding with untrusted input into any of these attributes or properties, their site may be exploitable. A databinding engine can do some things to protect against this. One way of handling this is to treat strings as untrusted by default, and require explicit wrapping types for trusted content, e.g. https://google.github.io/closure-library/api/goog.html.SafeUrl.html https://google.github.io/closure-library/api/goog.html.SafeU...
- jamescostian 8y agoDemo 2 seems to be a problem with jsfiddle: https://jsfiddle.net/hegLkz4s/22/ https://jsfiddle.net/hegLkz4s/22/ It's also already been reported: https://github.com/jsfiddle/jsfiddle-issues/issues/963 https://github.com/jsfiddle/jsfiddle-issues/issues/963 You're right about there being an XSS vulnerability here though. But you can fix it pretty easily by escaping the HTML: https://jsfiddle.net/hegLkz4s/17/ https://jsfiddle.net/hegLkz4s/17/
- dosy 8y agoMerged your PR!
- spankalee 8y agolit-html, a similar HTML templating with template literals library, achieves /mostly/ XSS-safe by default by never interpolating dynamic data before parsing, but interpolating after parsing and DOM construction and then using textContent, not innerHTML. That means that user-provided text can't inject markup into the page. There are still a number of sensitive attributes that we want to be automatically sanitized for you, like src/href/on*, but we have the hooks needed for that and just need to add the contextual sanitizer.
- franciscop 8y agoDoes it throw if a template returns a string? While it's a cool feature to be able to do this, it's also quite dangerous (specially when dealing with beginners for this library) to have these two behaving almost the same but one being safe and the other not: // Safe version const header = title => html`<h1>${title}</h1>`; // Unsafe version, but it "works" as expected const header = title => `<h1>${title}</h1>`;
- spankalee 8y agoIt doesn't throw, the unsafe version is just escaped by the browser: Let's consider a container where a function like `header` would be used: const page = (title, body) => html` ${header(title)} <p>${body}</p> `; If you use the safe version, you might get: <h1>Foo</h1> <p>Bar</p> but if you use the unsafe version, you'd get: <h1>Foo</h1> <p>Bar</p> See a demo here: https://stackblitz.com/edit/lit-html-escaping?file=index.js https://stackblitz.com/edit/lit-html-escaping?file=index.js
- franciscop 8y agoAh cool, that works as well from a security point of view. I slightly prefer throwing, but that is highly opinionated.