@koto Thanks for a detailed comment!

In general most of jQuery APIs seem to fit well into what we call "tt-agnostic" bucket. In other words, they should be able to accept TT instances (in place of strings) and pass them without modification to DOM.

Some of jQuery behavior violates that. For example, some of the tag wrapping code + self-closing tag expansion that was just changed due to XSS issues.

Fortunately, that function has been changed to an identity function in jQuery 3.5.0 so it'd no longer break a trusted type wrapped HTML.

Large parts of these patterns could be gated on browser checks, especially if they workaround some legacy browser behavior.

There's an important aspect here. jQuery generally avoids browser detection, instead opting for support tests. The master branch doesn't contain a lot of them right now as most were meant for IE which we now just detect via document.documentMode but that's the only browser sniffing we accept (as IE is feature-dead so the risk is low). Those feature tests sometimes need to use innerHTML-based assignments, see e.g. this test for a Safari 8 issue:
https://github.com/jquery/jquery/blob/3.5.1/src/core/support.js#L13-L17
While we don't have many tests like that - and none on master at the moment, we can't be sure there won't be a need for a new one in the future.

We already had to be careful here due to CSP issues which we test for:
https://github.com/jquery/jquery/blob/3.5.1/test/unit/support.js#L40-L55
but it doesn't block innerHTML as a whole which Trusted Types enforcement would do.

I feel this is a more generic issue with CSP, though: what we need is a way to run support tests in a secure way that's not blocked by CSP. The environment where we run them could be isolated from the real webpage in which case there would be no security risk even if we used inline code, raw HTML strings, etc. Is it likely we'll get something like that?

Some things still remain though, e.g. jQuery IIRC still expands <script> nodes and tries to execute them separately

That's a good argument for us to stop doing that by default in jQuery 4. This would be a significant breaking change, though, so we'd still need to add a non-default way to keep the old behavior.

Usually there is a way to become tt-agnostic with no backward compatibility issues without referencing TrustedTypes at all, as DOM APIs are very rarely called with Objects, and Trusted Type instances are Objects. Unfortunately, jQuery offers a very limited API for jQuery(plainObject) case. The only way I see is to not recognise TrustedTypes as isPlainObjects and introduce a branch for "immutable HTML objects" in jQuery(), opting them out of modifications. But this requires referencing TT.

This API only accepts plain objects, though. We could perhaps make that explicit & treat non-plain objects in a different manner. The only issue is that the jQuery() function mostly serves two purposes: as a shortcut of jQuery(cssSelector) to $(document).find(cssSelector) and as a mechanism to create new elements representing a provided HTML string which more or less depends on whether the string starts with <, possibly preceded by whitespace:
https://github.com/jquery/jquery/blob/3.5.1/src/core/init.js#L36-L41
or:
https://github.com/jquery/jquery/blob/3.5.1/src/core/init.js#L50-L51
This is such a fundamental property of the library that it's impossible to give up on this polymorphism. Maybe it's not an issue since trusted HTML stringifies to the underlying HTML, though, we'd just need to cast it to string before running the checks?

I feel a bit uneasy to explicitly mention the API in jQuery source; we've seen it a few times that APIs only supported by one browser may disappear or change significantly before being accepted accross all the major engines and then we'd often have to support both the old & new APIs. I'd like to first research how far we can go without relying on the API explicitly.

I'm happy to help with fleshing out the integration, or even brainstorming about issues with one. While I don't have tons experience with recent jQuery, we have done our share of TT integrations already and know some best practices and antipatterns. What would be the next best steps?

I think I'll first backport the AngularJS changes to jQuery master & then the next step would be to try to fix the jQuery() method to not break on trusted types via means I described above. For now I'd focus on the master branch; if we make it there, we could consider whether that's possible to backport to the 3.x line, although I'm a bit skeptical here.

It'd also help if we had an answer for how to handle support tests in a secure, CSP-compliant way; in particular, if we can get any browser APIs that would allow them to run in a sandboxed environment even with CSP enabled.

Have Trusted Types API built directly into the jQuery Core Files #4409

Description

Activity

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions