You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Blob constructor as well. We should require TrustedHTML if the Blob type is one of the HTML types. It seems fine to allow for contructing Blobs from non-DOMstring arguments.
While usually the blobs are used in new documents, like iframes, where they can simply trigger in-origin XSS from user input, they can also be used to create nodes from strings like this:
b = new Blob([`<script>alert(1)</script>`], {type: 'text/html'})
xhr = new XMLHttpRequest();
xhr.responseType = 'document';
xhr.open('GET', URL.createObjectURL(b), true);
xhr.send();
// ...
xhr.response.scripts[0] // a new script node.
…ascript: URLs. (#204)
This removes the burden from all authors to create types when interacting with common sinks that usually don't cause DOM XSS (unless for javascript: URLs).
This PR prevents javascript: URLs from working by default, and allows programmatic opt-in to enable them one-by-one for the few applications that need them.
Related to #176.
Partially addresses #169.
Fixes#64.
The sinks mentioned in #169 (comment) self-deprecated with TrustedURL.
Blob is complicated, and it seems like TT can't solve it alone. In general, TT are bypassable with a colluding same-origin document (https://w3c.github.io/webappsec-trusted-types/dist/spec/#cross-document-vectors) - a problem that Blobs surface. It looks like a better primitive would be to make Blobs inherit the creator's policies - w3c/FileAPI#142, or allow for cross-origin/sandboxed blob creation, perhaps by default.
There's also some URLs that don't seem to be used by the user agent in any way:
The text was updated successfully, but these errors were encountered: