Also add clarifying comments to the SRI WPT tests with
regards to the `www.` domain and how that interacts with
the integrity checks.
Lastly, adjust the casing for `Strict-Dynamic`, as in
the post-request check that should also be case-insensitive.
Closesservo/servo#37200Closesservo/servo#36760Fixesservo/servo#36499
Part of w3c/webappsec-csp#727Fixesw3c/webappsec-csp#728
Part of servo/servo#4577
Signed-off-by: Josh Matthews <josh@joshmatthews.net>
Signed-off-by: Tim van der Lippe <tvanderlippe@gmail.com>
Co-authored-by: Josh Matthews <josh@joshmatthews.net>
Rather than sharing the full image cache in a script_thread, the image
cache is now unique per document. This ensures that CSP factors no
longer affect whether the image is retrieved from the cache incorrectly.
To do so, the thread_pool is shared across all caches, but the store is
fresh. Except for the place_holder{image,url}, which are cloned. That's
because the `rippy_data` is only available in the constellation and no
longer accessible at the point that we need to create the document in
the script_thread.
Contrary to the description in #36505, the script_thread still has an
image_cache for this reason: so it has access to the store and
thread_pool to clone it.
With these changes, the two CSP tests no longer flake. Confirmed with
running the following commmand:
```
./mach test-wpt tests/wpt/tests/content-security-policy/generic/ --rerun=10
```
Fixes#36505
Signed-off-by: Tim van der Lippe <tvanderlippe@gmail.com>
This turned out to be a full rabbit hole. The new header
is parsed in the new `parse_csp_list_from_metadata` which
sets `disposition` to `report.
I was testing this with
`script-src-report-only-policy-works-with-external-hash-policy.html`
which was blocking the script incorrectly. Turns out that there
were multiple bugs in the CSP library, as well as a missing
check in `fetch` to report violations.
Additionally, in several locations we were manually reporting csp
violations, instead of the new `global.report_csp_violations`. As
a result of that, they would double report, since the report-only
header would be appended as a policy and now would report twice.
Now, all callsides use `global.report_csp_violations`. As a nice
side-effect, I added the code to set source file information,
since that was already present for the `eval` check, but nowhere
else.
Part of #36437
Requires servo/rust-content-security-policy#5
---------
Signed-off-by: Tim van der Lippe <tvanderlippe@gmail.com>
Signed-off-by: Tim van der Lippe <TimvdLippe@users.noreply.github.com>
We now check the sink of script.src for trusted types. This is the first
attribute that we check, other sinks will be implemented in follow-up
changes.
The algorithms currently hardcode various parts. That's because I need
to refactor a couple of algorithms already present in TrustedTypePolicy.
They use callbacks at the moment, which made sense for their initial
use. However, for these new algorithms they don't work. Therefore, I
will align them with the specification by taking in an enum. However,
since that's a bigger refactoring, I left that out of this PR (which is
already quite big).
The other trusted types support (createScript and createHTML) will also
be implemented separately.
Part of #36258
---------
Signed-off-by: Tim van der Lippe <tvanderlippe@gmail.com>
Signed-off-by: Tim van der Lippe <TimvdLippe@users.noreply.github.com>
Co-authored-by: Josh Matthews <josh@joshmatthews.net>
This also ensures that document now reports all violations and we set
the correct directive.
With these changes, all `script-src-attr-elem` WPT tests pass.
Part of #36437
Requires servo/rust-content-security-policy#3 to land first
Signed-off-by: Tim van der Lippe <tvanderlippe@gmail.com>
It also updates the FetchResponseListener to process CSP violations to
ensure that iframe elements (amongst others) properly generate the CSP
events. These iframe elements are used in the Trusted Types tests
themselves and weren't propagating the violations before.
However, the tests themselves are still not passing since they also use
Websockets, which currently aren't using the fetch machinery itself.
That is fixed as part of [1].
[1]: https://github.com/servo/servo/issues/35028
---------
Signed-off-by: Tim van der Lippe <tvanderlippe@gmail.com>
Signed-off-by: Josh Matthews <josh@joshmatthews.net>
Co-authored-by: Josh Matthews <josh@joshmatthews.net>
Extending the original set from #36402 since there are additional tests
relevant to the work happening in #36409 and #36363.
Testing: New tests in CI.
Fixes: Part of https://github.com/servo/servo/issues/4577
Signed-off-by: Josh Matthews <josh@joshmatthews.net>
