Open bzbarsky opened 7 years ago
I guess this is kinda handled in https://w3c.github.io/webappsec-csp/#initialize-document-csp sorta. But that's using the CSP of the parent or opener, not the CSP of wherever the blob came from, which is a bit odd.
And clearly at least Safari found this none too clear...
//cc @mikewest
Same as https://github.com/whatwg/html/issues/2592#issuecomment-868017904 , this is probably fixed in the spec but unsure if it's fully tested.
I think we can duplicate this against https://github.com/w3c/FileAPI/issues/142 and #4926, but I'm okay with keeping it open if we want a dedicated tracking issue.
Hi, I'm reading through the spec to understand the inheritance behavior for local schemes. I'm still trying to figure out if the correct behavior for blob:
URLs is to inherit the CSP from the URL creator or to inherit it from the navigation initiator.
this is probably fixed in the spec
According to browsing-the-web.html#navigating-across-documents, "determine navigation params policy container" is called after "create a policy container from a fetch response", so a blob URL would not inherit the responsePolicyContainer ("a clone of response's URL's blob URL entry's environment's policy container") but the initiatorPolicyContainer (step 3 of "determine navigation params policy container" origin.html#policy-containers).
This matches the CSP spec (#security-inherit-csp) but seems to contradict the behavior defined for blob URLs in @antosart's policy container explainer. Am I reading it wrong?
but unsure if it's fully tested
In wpt/content-security-policy/inheritance, all tests concerning blob:
URLs do not differentiate the creation and navigation steps. I quickly tested the behavior by modifying blob-url-inherits-from-initiator.sub.html so that createObjectURL
and window.location
are executed in two different same-origin iframes (see wert310/wpt/blob-url-inherits-from-creator).
In the current dev versions of Chrome (93.0.4573.0) and Firefox (92.0a1), blob:
URLs do not inherit from the creator of the URL but from the initiator of the navigation.
If the plan is to inherit the policy from the creator, the CSP of the navigator could be stripped by navigating to a blob:
whose creator does not have a CSP. I see this as a variation of bugs.chromium/894228 where the policy of the inner frame is discarded and replaced with a weaker one after the navigation.
The goal is to inherit the policies from the creator. I believe you are right and there is a bug in the spec. I created #6895 to fix this.
Regarding tests, you are right that we don't have specific tests for this. The problem in writing tests here is that no vendor (at least that I know of) implements this at the moment, although in chrome we would like to address this at some point. (Note that since blob URLs can only be navigated from the same-origin, I believe the security implications of this are very low.)
I think we should merge the tests you created, though, even if they are failing on all vendors.
I see nothing involving CSP anywhere in https://w3c.github.io/FileAPI/ and I don't see the blob steps in https://fetch.spec.whatwg.org/#basic-fetch doing anything with CSP. There's nothing in the HTML spec that would give blob: any particular CSP.
So it looks to me like things loaded from blob: do not have CSP applying to them, per spec.
Using this testcase:
I see the following behavior: