Have Trusted Types API built directly into the jQuery Core Files #4409
Comments
|
Thanks for the report. What would you expect jQuery to do here? |
|
Note, though, that jQuery doesn't support experimental APIs as they may change and then we're left with obsolete code. It's fine to experiment & think of the approaches but we'd wait with landing any actual code in the library for the spec to stabilize & to be implemented in at least 2 major browser engines. |
|
Yeah, this is a tough one. The team has discussed it for years and had issues determining how to make things safer without seriously redesigning the API. Most of our HTML goes through Perhaps we could recognize a Trusted Type and pass it through as if were HTML, but not actually do any manipulation with it, e.g. Seems like they've taken old browsers into account with a simple polyfill that just returns strings if the browser doesn't support Trusted Types. But given where the implementations are at, it is probably too early to add any code. |
|
I will add an extra comment as you added a 'needs info' label. I totally understand that the Trusted Types API is right now in a trial. I thought maybe this issue could be dealt with in your future updates like in V4.0.0 and by then the API would have changed from a trial / draft spec to a more stable spec. When I did a quick play around with Trusted Types API and jQuery V3.4.1 I got the following results:
DomPurifer have added this API see here for further details: https://github.com/cure53/DOMPurify#what-about-dompurify-and-trusted-types I can't really say anymore and leave this issue open to other people to comment and add extra info and ideas. I feel it would be a good feature request for jQuery in the near future and decided to open this issue in that regard. We all know about this problem for a long time, but a full solution has never been added yet. |
|
I added it to the 4.0.0 milestone so that we don’t forget about it when we get closer to the release. |
|
I'm in favor of this. We'll keep an eye on the spec status and revisit later. |
ghost
mentioned this issue
|
angular/angular.js#17028 has some code that I'd like to backport to jQuery, at least to the |
|
Bringing in the comment from angular/angular.js#17028
To clarify, TT are intended to be rolled out as a regular web API, but you're correct - for now this is only implemented in Blink (and polyfilled in other browsers).
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. Large parts of these patterns could be gated on browser checks, especially if they workaround some legacy browser behavior. Some things still remain though, e.g. jQuery IIRC still expands 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 Adding such support should not cause b/w compatibility issues, as it's simply a new way of using jQuery APIs (one that happens not to violate TT restrictions that might be present in your CSP), that some applications may use. I'm confident that with relatively small changes we might be able to support most use cases. That said, I'm a bit skeptical all applications using jQuery could migrate to "TT mode" by a single configuration switch. Quite likely some jQuery functions would have to change the behavior, error out, or produce types internally when called with Trusted Types ( One important thing to note is that TT should not be treated as "better strings for HTML", and you should never return a Trusted Type when the caller expects a string - we got bit by this when making 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? |
|
@koto Thanks for a detailed comment!
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.
There's an important aspect here. jQuery generally avoids browser detection, instead opting for support tests. The We already had to be careful here due to CSP issues which we test for: 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?
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.
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 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 think I'll first backport the AngularJS changes to jQuery 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. |
Concatenating HTML strings in buildFragment is a possible security risk as it creates an opportunity of escaping the concatenated wrapper. It also makes it impossible to support secure HTML wrappers like [trusted types](https://web.dev/trusted-types/). It's safer to create wrapper elements using `document.createElement` & `appendChild`. The previous way was needed in jQuery <4 because IE <10 doesn't accept table parts set via `innerHTML`, even if the element which contents are set is a proper table element, e.g.: ```js tr.innerHTML = "<td></td>"; ``` The whole structure needs to be passed in one HTML string. jQuery 4 drops support for IE <11 so this is no longer an issue; in older version we'd have to duplicate the code paths. IE <10 needed to have `<option>` elements wrapped in `<select multiple="multiple">` but we no longer need that on master which makes the `document.createElement` way shorter. jQuery 1.x sometimes needed to have more than one element in the wrapper that would precede parts wrapping HTML input so descending needed to use `lastChild`. Since all wrappers are single-element now, we can use `firstChild` which compresses better as it's used in other places in the code as well. All these improvements, apart from making logic more secure, decrease the gzipped size by 55 bytes. Ref gh-4409
|
The first PR (backporting some AngularJS changes) is ready for review at #4724. |
Concatenating HTML strings in buildFragment is a possible security risk as it creates an opportunity of escaping the concatenated wrapper. It also makes it impossible to support secure HTML wrappers like [trusted types](https://web.dev/trusted-types/). It's safer to create wrapper elements using `document.createElement` & `appendChild`. The previous way was needed in jQuery <4 because IE <10 doesn't accept table parts set via `innerHTML`, even if the element which contents are set is a proper table element, e.g.: ```js tr.innerHTML = "<td></td>"; ``` The whole structure needs to be passed in one HTML string. jQuery 4 drops support for IE <11 so this is no longer an issue; in older version we'd have to duplicate the code paths. IE <10 needed to have `<option>` elements wrapped in `<select multiple="multiple">` but we no longer need that on master which makes the `document.createElement` way shorter. jQuery 1.x sometimes needed to have more than one element in the wrapper that would precede parts wrapping HTML input so descending needed to use `lastChild`. Since all wrappers are single-element now, we can use `firstChild` which compresses better as it's used in other places in the code as well. All these improvements, apart from making logic more secure, decrease the gzipped size by 55 bytes. Ref jquerygh-4409
Concatenating HTML strings in buildFragment is a possible security risk as it creates an opportunity of escaping the concatenated wrapper. It also makes it impossible to support secure HTML wrappers like [trusted types](https://web.dev/trusted-types/). It's safer to create wrapper elements using `document.createElement` & `appendChild`. The previous way was needed in jQuery <4 because IE <10 doesn't accept table parts set via `innerHTML`, even if the element which contents are set is a proper table element, e.g.: ```js tr.innerHTML = "<td></td>"; ``` The whole structure needs to be passed in one HTML string. jQuery 4 drops support for IE <11 so this is no longer an issue; in older version we'd have to duplicate the code paths. IE <10 needed to have `<option>` elements wrapped in `<select multiple="multiple">` but we no longer need that on master which makes the `document.createElement` way shorter as we don't have to call `setAttribute`. jQuery 1.x sometimes needed to have more than one element in the wrapper that would precede parts wrapping HTML input so descending needed to use `lastChild`. Since all wrappers are single-element now, we can use `firstChild` which compresses better as it's used in other places in the code as well. All these improvements, apart from making logic more secure, decrease the gzipped size by 55 bytes. Ref jquerygh-4409
Concatenating HTML strings in buildFragment is a possible security risk as it creates an opportunity of escaping the concatenated wrapper. It also makes it impossible to support secure HTML wrappers like [trusted types](https://web.dev/trusted-types/). It's safer to create wrapper elements using `document.createElement` & `appendChild`. The previous way was needed in jQuery <4 because IE <10 doesn't accept table parts set via `innerHTML`, even if the element which contents are set is a proper table element, e.g.: ```js tr.innerHTML = "<td></td>"; ``` The whole structure needs to be passed in one HTML string. jQuery 4 drops support for IE <11 so this is no longer an issue; in older version we'd have to duplicate the code paths. IE <10 needed to have `<option>` elements wrapped in `<select multiple="multiple">` but we no longer need that on master which makes the `document.createElement` way shorter as we don't have to call `setAttribute`. jQuery 1.x sometimes needed to have more than one element in the wrapper that would precede parts wrapping HTML input so descending needed to use `lastChild`. Since all wrappers are single-element now, we can use `firstChild` which compresses better as it's used in other places in the code as well. All these improvements, apart from making logic more secure, decrease the gzipped size by 55 bytes. Ref jquerygh-4409 Ref angular/angular.js#17028
Understood. There's always a possibility that
I'm not sure I understand fully the use case here. Is this about production code doing feature testing that clashes with some CSP restrictions, or being able to configure the test environment easily? Can you reduce it to the smallest code snippet to distill the issue? In any case, browser changes take years to deploy, so it's not great either way :/
Understood. In general I think we can't get away with some configuration settings to control the behavior - after all, the whole idea is to reduce the attack surface, so it feels OK if jQuery users could voluntarily simply turn off the settings they don't need or find problematic. Trusted Types are here just an easy way of surfacing those risky areas. The exact shape of the configuration and what should the defaults be is of course decided by library owners.
The problem I'm seeing is I don't know how to distinguish POJO (or even typed objects) from Trusted Type objects without literally having One of the ideas of making the lib TT agnostic would be e.g. allowing the users to specify which types they want jQuery to passthrough: and then jQuery would just make a
If you're sure an object with a
Of course, no disagreements here - if it turns out feasible, that's ideal.
I want to hear more about that. I'm not sure I'm answering the right question here, but there is a way to "break-out" of CSP restrictions, including Trusted Types. You either iframe a separate document that was loaded from a server (CSPs don't inherit), or iframe a Slightly tangential to this, we were considering exposing a JS API to probe for the current CSP restrictions (https://w3c.github.io/webappsec-csp/api/ and w3c/trusted-types#36), but we did not have strong enough use cases for this. |
Concatenating HTML strings in buildFragment is a possible security risk as it creates an opportunity of escaping the concatenated wrapper. It also makes it impossible to support secure HTML wrappers like [trusted types](https://web.dev/trusted-types/). It's safer to create wrapper elements using `document.createElement` & `appendChild`. The previous way was needed in jQuery <4 because IE <10 doesn't accept table parts set via `innerHTML`, even if the element which contents are set is a proper table element, e.g.: ```js tr.innerHTML = "<td></td>"; ``` The whole structure needs to be passed in one HTML string. jQuery 4 drops support for IE <11 so this is no longer an issue; in older version we'd have to duplicate the code paths. IE <10 needed to have `<option>` elements wrapped in `<select multiple="multiple">` but we no longer need that on master which makes the `document.createElement` way shorter as we don't have to call `setAttribute`. jQuery 1.x sometimes needed to have more than one element in the wrapper that would precede parts wrapping HTML input so descending needed to use `lastChild`. Since all wrappers are single-element now, we can use `firstChild` which compresses better as it's used in other places in the code as well. All these improvements, apart from making logic more secure, decrease the gzipped size by 55 bytes. Ref jquerygh-4409 Ref angular/angular.js#17028
One example is the test case I provided before: https://github.com/jquery/jquery/blob/3.5.1/src/core/support.js#L13-L17. It's a test for a Safari 8 issue and it requires Things like that would be impossible on pages that enforce trusted types via CSP right now. I feel that browsers need an API that would allow to bypass CSP for test cases like that in a secure way (i.e. no access to cookies/other types of storage, to the current DOM, etc.). ...unless this works:
Since this is a library we can't really load anything else from the server other than what the user already loads but if an iframe with a blob URL works, that's worth checking for a potential future use.
jQuery has a Lines 202 to 221 in 40c3abd It's true we have to be mindful about performance but this API is already used in another place in the jQuery.fn.init code so it might be doable.
I think at the beginning I'd try to do it without explicit hatches like that to increase probability of at least some jQuery plugins working with trusted types out of the box but I'll keep this in mind if that doesn't work.
This would be an edge case so I think it's fine for a major update at least. |
mgol
added
Manipulation
Discuss in Meeting
|
I submitted a pull request adding support for TrustedHTML, including unit tests, please take a look: #4927. @koto could you give an update of where we are with regards to browser support? Are maintainers of other browser engines in favor, neutral or opposed to the standard? Such information matters a lot for a project like jQuery. |
|
Thanks a lot, @mgol, I'll take a look at the PR (I already like the ones merged!). The code size delta is impressively small! There are sadly no updates w.r.t. to other browsers support. Trusted Types are currently shipped in Edge, Chrome, Opera, Blink etc.) + there is a polyfill. We see the usage of the API slowly growing, and have released a report of the current TT coverage. The recent large integrations we know of are Angular and webpack. For library integrations, we are trying to make sure that the code, either:
That way many integrations bring value even without the TT enforcement due to untangling their data flows. My biased take is that this is worth +38 bytes, but these are obviously not my bytes to govern :) |
|
@koto Thanks for the updates. Up to 4.5% of page loads with TT enforcement in Chrome looks like a lot! Do you know what pages contribute the most to such a percentage? I imagine the vast majority of web developers doesn't even know about trusted types so I'd expect such traffic to come mostly from a few popular websites. EDIT: I should have looked at the report before asking, I see there's more detailed data there. :) |
This ensures HTML wrapped in TrustedHTML can be used as an input to jQuery manipulation methods in a way that doesn't violate the `require-trusted-types-for` Content Security Policy directive. This commit builds on previous work needed for trusted types support, including jquerygh-4642 and jquerygh-4724. One restriction is that while any TrustedHTML wrapper should work as input for jQuery methods like `.html()` or `.append()`, for passing directly to the `jQuery` factory the string must start with `<` and end with `>`; no trailing or leading whitespaces are allowed. This is necessary as we cannot parse out a part of the input for further construction; that would violate the CSP rule - and that's what's done to HTML input not matching these constraints. No trusted types API is used explicitly in source; the majority of the work is ensuring we don't pass the input converted to string to APIs that would eventually assign it to `innerHTML`. This extra cautiousness is caused by the API being Blink-only, at least for now. The ban on passing strings to `innerHTML` means support tests relying on such assignments are impossible. We don't currently have such tests on the `main` branch but we used to have many of them in the 3.x & older lines. If there's a need to re-add such a test, we'll need an escape hatch to skip them for apps needing CSP-enforced TrustedHTML. See https://web.dev/trusted-types/ for more information about TrustedHTML. Fixes jquerygh-4409 Ref jquerygh-4642 Ref jquerygh-4724
This ensures HTML wrapped in TrustedHTML can be used as an input to jQuery manipulation methods in a way that doesn't violate the `require-trusted-types-for` Content Security Policy directive. This commit builds on previous work needed for trusted types support, including jquerygh-4642 and jquerygh-4724. One restriction is that while any TrustedHTML wrapper should work as input for jQuery methods like `.html()` or `.append()`, for passing directly to the `jQuery` factory the string must start with `<` and end with `>`; no trailing or leading whitespaces are allowed. This is necessary as we cannot parse out a part of the input for further construction; that would violate the CSP rule - and that's what's done to HTML input not matching these constraints. No trusted types API is used explicitly in source; the majority of the work is ensuring we don't pass the input converted to string to APIs that would eventually assign it to `innerHTML`. This extra cautiousness is caused by the API being Blink-only, at least for now. The ban on passing strings to `innerHTML` means support tests relying on such assignments are impossible. We don't currently have such tests on the `main` branch but we used to have many of them in the 3.x & older lines. If there's a need to re-add such a test, we'll need an escape hatch to skip them for apps needing CSP-enforced TrustedHTML. See https://web.dev/trusted-types/ for more information about TrustedHTML. Fixes jquerygh-4409 Ref jquerygh-4642 Ref jquerygh-4724
|
I have a Chrome extension that uses Jquery, I am now getting about 5 "This document requires 'TrustedHTML' assignment" errors in the Chrome console whenever the browser loads jquery, causing the extension to stop working (because Jquery failed to load due to the error mentioned above). I tried the latest version 3.6 and got the same error. Apparently, Jquery uses innerHTML somewhere in the code, so I had to window.trustedTypes to bypass the failure, it's more a hack. Thanks |
|
@zwjohn I don't know exactly your setup, but I believe some feature testing done by jQuery at load times interfere with Trusted Types restrictions your Chrome extension has (or the restriction the page has, where the extension is loading its content script). I "fixed" this in the past by using the default policy (the code is old, so it might need some adjusting: https://github.com/koto/web/blob/trusted-types-angular/src/trusted-types/default.ts). Note that it will not address any other DOM writes you might be doing through jQuery or its plugins. |
|
@koto thanks for sharing your solution, I will take a look. I could use DOMPurify library to purify the strings, however, I think Jquery should handle this in the library or replace usage of innerHTML to avoid this error, otherwise, every developer using Jquery will run into this issue sooner or later. |
This ensures HTML wrapped in TrustedHTML can be used as an input to jQuery manipulation methods in a way that doesn't violate the `require-trusted-types-for` Content Security Policy directive. This commit builds on previous work needed for trusted types support, including jquerygh-4642 and jquerygh-4724. One restriction is that while any TrustedHTML wrapper should work as input for jQuery methods like `.html()` or `.append()`, for passing directly to the `jQuery` factory the string must start with `<` and end with `>`; no trailing or leading whitespaces are allowed. This is necessary as we cannot parse out a part of the input for further construction; that would violate the CSP rule - and that's what's done to HTML input not matching these constraints. No trusted types API is used explicitly in source; the majority of the work is ensuring we don't pass the input converted to string to APIs that would eventually assign it to `innerHTML`. This extra cautiousness is caused by the API being Blink-only, at least for now. The ban on passing strings to `innerHTML` means support tests relying on such assignments are impossible. We don't currently have such tests on the `main` branch but we used to have many of them in the 3.x & older lines. If there's a need to re-add such a test, we'll need an escape hatch to skip them for apps needing CSP-enforced TrustedHTML. See https://web.dev/trusted-types/ for more information about TrustedHTML. Fixes jquerygh-4409 Ref jquerygh-4642 Ref jquerygh-4724
This ensures HTML wrapped in TrustedHTML can be used as an input to jQuery manipulation methods in a way that doesn't violate the `require-trusted-types-for` Content Security Policy directive. This commit builds on previous work needed for trusted types support, including jquerygh-4642 and jquerygh-4724. One restriction is that while any TrustedHTML wrapper should work as input for jQuery methods like `.html()` or `.append()`, for passing directly to the `jQuery` factory the string must start with `<` and end with `>`; no trailing or leading whitespaces are allowed. This is necessary as we cannot parse out a part of the input for further construction; that would violate the CSP rule - and that's what's done to HTML input not matching these constraints. No trusted types API is used explicitly in source; the majority of the work is ensuring we don't pass the input converted to string to APIs that would eventually assign it to `innerHTML`. This extra cautiousness is caused by the API being Blink-only, at least for now. The ban on passing strings to `innerHTML` means support tests relying on such assignments are impossible. We don't currently have such tests on the `main` branch but we used to have many of them in the 3.x & older lines. If there's a need to re-add such a test, we'll need an escape hatch to skip them for apps needing CSP-enforced TrustedHTML. See https://web.dev/trusted-types/ for more information about TrustedHTML. Fixes jquerygh-4409 Ref jquerygh-4642 Ref jquerygh-4724
This ensures HTML wrapped in TrustedHTML can be used as an input to jQuery manipulation methods in a way that doesn't violate the `require-trusted-types-for` Content Security Policy directive. This commit builds on previous work needed for trusted types support, including jquerygh-4642 and jquerygh-4724. One restriction is that while any TrustedHTML wrapper should work as input for jQuery methods like `.html()` or `.append()`, for passing directly to the `jQuery` factory the string must start with `<` and end with `>`; no trailing or leading whitespaces are allowed. This is necessary as we cannot parse out a part of the input for further construction; that would violate the CSP rule - and that's what's done to HTML input not matching these constraints. No trusted types API is used explicitly in source; the majority of the work is ensuring we don't pass the input converted to string to APIs that would eventually assign it to `innerHTML`. This extra cautiousness is caused by the API being Blink-only, at least for now. The ban on passing strings to `innerHTML` means support tests relying on such assignments are impossible. We don't currently have such tests on the `main` branch but we used to have many of them in the 3.x & older lines. If there's a need to re-add such a test, we'll need an escape hatch to skip them for apps needing CSP-enforced TrustedHTML. See https://web.dev/trusted-types/ for more information about TrustedHTML. Fixes jquerygh-4409 Ref jquerygh-4642 Ref jquerygh-4724
This ensures HTML wrapped in TrustedHTML can be used as an input to jQuery manipulation methods in a way that doesn't violate the `require-trusted-types-for` Content Security Policy directive. This commit builds on previous work needed for trusted types support, including jquerygh-4642 and jquerygh-4724. One restriction is that while any TrustedHTML wrapper should work as input for jQuery methods like `.html()` or `.append()`, for passing directly to the `jQuery` factory the string must start with `<` and end with `>`; no trailing or leading whitespaces are allowed. This is necessary as we cannot parse out a part of the input for further construction; that would violate the CSP rule - and that's what's done to HTML input not matching these constraints. No trusted types API is used explicitly in source; the majority of the work is ensuring we don't pass the input converted to string to APIs that would eventually assign it to `innerHTML`. This extra cautiousness is caused by the API being Blink-only, at least for now. The ban on passing strings to `innerHTML` means support tests relying on such assignments are impossible. We don't currently have such tests on the `main` branch but we used to have many of them in the 3.x & older lines. If there's a need to re-add such a test, we'll need an escape hatch to skip them for apps needing CSP-enforced TrustedHTML. See https://web.dev/trusted-types/ for more information about TrustedHTML. Fixes jquerygh-4409 Ref jquerygh-4642 Ref jquerygh-4724
This ensures HTML wrapped in TrustedHTML can be used as an input to jQuery manipulation methods in a way that doesn't violate the `require-trusted-types-for` Content Security Policy directive. This commit builds on previous work needed for trusted types support, including gh-4642 and gh-4724. One restriction is that while any TrustedHTML wrapper should work as input for jQuery methods like `.html()` or `.append()`, for passing directly to the `jQuery` factory the string must start with `<` and end with `>`; no trailing or leading whitespaces are allowed. This is necessary as we cannot parse out a part of the input for further construction; that would violate the CSP rule - and that's what's done to HTML input not matching these constraints. No trusted types API is used explicitly in source; the majority of the work is ensuring we don't pass the input converted to string to APIs that would eventually assign it to `innerHTML`. This extra cautiousness is caused by the API being Blink-only, at least for now. The ban on passing strings to `innerHTML` means support tests relying on such assignments are impossible. We don't currently have such tests on the `main` branch but we used to have many of them in the 3.x & older lines. If there's a need to re-add such a test, we'll need an escape hatch to skip them for apps needing CSP-enforced TrustedHTML. See https://web.dev/trusted-types/ for more information about TrustedHTML. Fixes gh-4409 Closes gh-4927 Ref gh-4642 Ref gh-4724
|
This has landed in #4927 and will be included in jQuery 4.0.0. Thanks for all the discussions! |
|
Thank you Michał, that's great news! |
|
I noticed one violation still in There is a workaround via It seems like this was introduced in ff75767, I suspect to workaround an IE <= 9 bug, which incorrectly stringified objects passed to I'm not sure what the most elegant solution would be here, I guess it depends on whether jQuery 4 aims to support IE9. If not, it's safe not to stringify values (browser API would). If yes, then there's only a less-than-ideal option of testing for the bug? IIRC this would be a good test: |
|
@koto Thanks for the info. jQuery 4.x will only support IE 11 so if this was just to please IE <=9 we should be good to remove the manual stringification. |
For example jQuery 3.x is not ready jquery/jquery#4409 Partially reverts #8
and others
The latest version of jQuery V3.4.1 has 5
innerHTML()which are not sanitized by default. Does the jQuery team plan on addressing these DOM XSS things in the near future with regards to the new Trusted Types API see here: https://github.com/WICG/trusted-typesThe text was updated successfully, but these errors were encountered: