Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(client): Add trusted types support #3360

Merged
merged 1 commit into from
Sep 9, 2019
Merged

feat(client): Add trusted types support #3360

merged 1 commit into from
Sep 9, 2019

Conversation

rictic
Copy link
Contributor

@rictic rictic commented Sep 3, 2019

With this change, Karma tests can be run with an enforced Trusted Types policy.

This change consists of using safer APIs (appendChild and textContent instead of innerHTML), as well as creating a policy for client/karma.js which a test's Trusted Types CSP policy can then explicitly allow. This policy is used internally where karma does potentially dangerous operations like loading scripts.

More info about the proposed Trusted Types standard at https://github.com/WICG/trusted-types

With this change, Karma tests can be run with an enforced Trusted Types policy.

This change consists of using safer APIs (appendChild and textContent instead of innerHTML), as well as creating a policy for client/karma.js which a test's Trusted Types CSP policy can then explicitly allow. This policy is used internally where karma does potentially dangerous operations like loading scripts.

More info about the proposed Trusted Types standard at https://github.com/WICG/trusted-types
@johnjbarton
Copy link
Contributor

I'll try to restart appveyor

@rictic
Copy link
Contributor Author

rictic commented Sep 5, 2019

For what it's worth, I've run this across all affected tests inside of google3, and all passed

@johnjbarton johnjbarton merged commit 019bfd4 into karma-runner:master Sep 9, 2019
@rictic rictic deleted the trusted-types branch September 9, 2019 17:51
rictic added a commit to rictic/mocha that referenced this pull request Sep 15, 2020
Trusted Types is a new Content Security Policy specification,
currently implemented in browsers based on Chromium 83 or higher, which
requires that data passed to APIs which may result in arbitrary code
execution must go through an explicit policy. This helps to catch
unintended use of dangerous APIs, and reduces the surface area for
some security reviews.

I'm not sure if test infrastructure like mocha is a likely target
for attack – seems like in most cases an attacker could only access test
data, and it is rare for tests to handle untrusted data. However,
there's value for infrastructure to be compatible with running with
Trusted Types enabled, as it will allow users to write tests to ensure
that the code under test can run with Trusted Types.

This change creates and applies policies for the two places in mocha
that call innerHTML, and adds a temporary patch to the rollup build.
With those changes in place, we can run mocha's karma tests with
Trusted Types enabled (save for the one test that runs with requirejs,
which relies on eval).

More info:

* Spec: https://w3c.github.io/webappsec-trusted-types/dist/spec/#introduction
* Related PR adding support to karma: karma-runner/karma#3360
@franktopel
Copy link

franktopel commented Nov 30, 2020

I cannot find this in the documentation anywhere. How do I enable this feature?

I've tried using

customHeaders: [
    {
        match: '\\.html',
        name: 'Content-Security-Policy',
        value: `require-trusted-types-for 'script';`,
    },
],

and written the following test

it('assigning a string to innerHTML violates the CSP', function() {
    let cspViolated = false;
    window.addEventListener('securitypolicyviolation', () => cspViolated = true);
    document.body.innerHTML = 'foo';
    expect(cspViolated).to.be.true;
    expect(document.body.innerHTML).to.not.equal('foo');
});

Unfortunately, the test fails.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants