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

Jump to bottom

Order of CSP, COEP, CORP, COOP, etc. checks don't match chromium #6564

Open
zcorpan opened this issue Apr 7, 2021 · 4 comments
Open

Order of CSP, COEP, CORP, COOP, etc. checks don't match chromium #6564

zcorpan opened this issue Apr 7, 2021 · 4 comments
Labels
topic: cross-origin-embedder-policy Issues and ideas around the new "require CORP for subresource requests and frames and etc" proposal. topic: cross-origin-opener-policy Issues and ideas around the new "inverse of rel=noopener" header.

Comments

@zcorpan
Copy link
Member

zcorpan commented Apr 7, 2021

I wrote a test to test ordering of COEP reporting vs CSP and X-Frame-Options, and was a bit puzzled by the observed outcome in chromium. @ArthurSonzogni commented:

You compared COEP and CSPEE (CSP embedded enforcement). The real CSP check is later
The current order is CSPEE < COEP < CSP in Chrome.

For now, in Chrome after receiving the navigation response:

  1. Check CSP embedded enforcement.
  2. Check COEP/CORP
  3. Check COOP vs sandbox
  4. Check download
  5. Check CSP (navigate-to, frame-src, prefetch-src, etc...) + before & after UpgradeInsecureRequest in the middle.
  6. Check CSP frame-ancestors
  7. Check X-Frame-Option

For now, my reading of the spec is:

  1. Check CSP (every directives)
  2. Check COEP
  3. Check X-Frame-Option
  4. [Check download]

Originally posted by @ArthurSonzogni in web-platform-tests/wpt#28281 (comment)

What do Gecko and WebKit do?

I don't see "CSP embedded enforcement" as a term in the CSP or HTML specs.

For upgrade insecure requests, I see https://fetch.spec.whatwg.org/#concept-main-fetch step 5, but don't know if it matches Chromium.
@zcorpan zcorpan added topic: cross-origin-opener-policy Issues and ideas around the new "inverse of rel=noopener" header. topic: cross-origin-embedder-policy Issues and ideas around the new "require CORP for subresource requests and frames and etc" proposal. labels Apr 7, 2021
@ArthurSonzogni
Copy link
Member

ArthurSonzogni commented Apr 7, 2021 •
edited

Firefox doesn't implement CSP embedded enforcement and I believe the spec is a "monkey-patch" that is injected into the HTML spec from:
https://www.w3.org/TR/csp-embedded-enforcement/#html-integration
(step 3)

@antosart @mikewest FYI.

@domenic
Copy link
Member

domenic commented Apr 7, 2021

Replying to web-platform-tests/wpt#28281 (comment):

Following the current spec: checking COEP in between CSP and X-Frame-Option seems complex, because we currently check both CSP:frame-ancestors and X-Frame-Option together in Chrome. They are about the exact same thing.
Moving the COEP check one step earlier in the spec would be much simpler.

Part of the issue is that the CSP specs want to handle all CSP things together. So grouping CSP: frame-ancestors and XFO is a bit unnatural.

We could probably make it work by just putting CSP-in-general and XFO together, and relying on the fact that (IIUC) the individual CSP checks do not have a defined order. So if we change the spec to COEP -> CSP -> XFO or CSP -> XFO -> COEP then implementations can always put the frame-ancestors CSP check after/before other CSP checks and thus put it together with XFO.

However, I don't know what other web implementations would prefer.

I suspect they'd be OK with changes here since COEP is relatively new (and only implemented in Gecko and Chromium). Maybe @annevk can help confirm.

@zcorpan zcorpan mentioned this issue Apr 8, 2021
Merged
ArthurSonzogni added a commit to ArthurSonzogni/html that referenced this issue Apr 11, 2021
@ArthurSonzogni
Check COEP one step earlier.
3f94b82 
When receiving a navigation response, the current HTML specification
checks policies in the following order:
- Check CSP
- Check COEP/CORS
- Check X-Frame-Options

X-Frame-Options and CSP:frame-ancestors are very close. They serve the
same purpose. CSP:frame-ancestors is the same thing, but more flexible.
It overrides X-Frame-Options when defined. They are also warning being
displayed to developers when they are using unreasonable combination of
both.

The check about COEP in between CSP and X-Frame-Options is unfortunately
badly placed. This patch propose checking it one step earlier.

Related issues::
- zcorpan@ tested ordering:
web-platform-tests/wpt#28281
- zcorpan@ opened an issue about inconsistencies about the specification
and Chromimum
whatwg#6564
@ArthurSonzogni
Copy link
Member

I wrote: ArthurSonzogni@3f94b82

If @annevk is interested, I will propose this PR, and update zcorpan@ WPT test expectation.

@annevk
Copy link
Member

annevk commented Apr 12, 2021

No strong opinion, but I believe Firefox does implement CSP reporting so you can probably find out our current order. I do agree it's good to define and test order. 😊

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
topic: cross-origin-embedder-policy Issues and ideas around the new "require CORP for subresource requests and frames and etc" proposal. topic: cross-origin-opener-policy Issues and ideas around the new "inverse of rel=noopener" header.
Milestone
No milestone
Development

No branches or pull requests
4 participants
@zcorpan @domenic @annevk @ArthurSonzogni