Consider implicit node / subtree adoption about trusted-types HOT 4 CLOSED

Somewhat related: DOMParser.parseFromString (https://w3c.github.io/DOM-Parsing/#the-domparser-interface) returns a Document. Should parseFromString be considered a HTML sink, and hence require TrustedHTML?

Conversely, DOMParser is used as the building block of HTML sanitizers (https://github.com/cure53/DOMPurify/blob/987a1e5569a7a4d4db97a145a51ff1ceafde9b89/src/purify.js#L380), in which context it's assumed that it's safe to pass untrusted HTML to it (as long as the resulting Document is not attached without further sanitization).

The DOM-Parsing spec has no "security considerations" section, so it's not quite clear whether the intent is that parsing untrusted HTML is safe.

from trusted-types.

I've covered these document-creating functions in #50.

from trusted-types.

Regarding node adoption, it's an interesting case:

https://gadgets.kotowicz.net/poc/xss/?xss=%3Cscript%3EsetTimeout(_=%3Edocument.body.appendChild(frames[0].document.body.children[0]),%201000)%3C/script%3E%3Ciframe%20srcdoc=%22%3Cimg%20src=https://www.google.com/images/branding/googlelogo/2x/googlelogo_color_272x92dp.png%20onload=%27alert(location.href)%27%3E%22%3E

In Chrome, it seems that the scripts execute with from their original realm even after implicit adoption. If FF, this is behaving as expected.

My take on this would be to consider this out of scope. Same origin documents can also just script you directly. It's not the exact same vector, as here the TT-ed document is actively initiating the potentially malicious action, but this feels like an intentional I'm-going-out-of-my-way bypass.

from trusted-types.

Re: node adoption, we decided to put it out of scope for v1, and to add it as a security consideration:

https://wicg.github.io/trusted-types/dist/spec/##cross-document-vectors

from trusted-types.