Subresource Integrity incorrectly requires CORS for same-origin resource
Reported by
gsuberl...@gmail.com,
Aug 31 2016
|
|||||
Issue descriptionISSUE DETAILS When specifying an SRI integrity attribute on an element which exists on the same domain as the current document (i.e. the same origin), Chrome incorrectly rejects the document with the following error message: "Subresource Integrity: The resource 'https://example.com/style.css' has an integrity attribute, but the resource requires the request to be CORS enabled to check the integrity, and it is not. The resource has been blocked because the integrity cannot be enforced." The above example assumes that the style.css document was being loaded from the index document at https://example.com/. This occurs regardless of whether the resource is referred to with a leading slash or as a full URI. A workaround is to provide the crossorigin="anonymous" attribute, which Chrome is expecting, though this should not be necessary for resources from the same origin. While there is no immediate direct security impact to the bug itself, it does result in sites having to allow CORS requests on the URI unnecessarily, which potentially negatively impacts the security posture of the page. This case is correctly handled in Firefox 48.0 and the resource is successfully loaded. VERSION Chrome Version: Version 52.0.2743.116 m stable Operating System: Microsoft Windows 10 Pro REPRODUCTION CASE I have SRI configured here, which should demonstrate the issue: https://poly.nomial.co.uk/ Thanks.
,
Aug 31 2016
,
Aug 31 2016
Hrm. The check at https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/fetch/Resource.cpp?sq=package:chromium&dr=CSs&rcl=1472628123&l=443 should be taking care of the same-origin case (via the call to `canRequest`).
,
Aug 31 2016
Oh, I see. You're sending a `sandbox` directive in your page's policy. That means that it's not actually same-origin with the resources that it's loading. We ought to require CORS here. I'm not sure whether Firefox supports the `sandbox` attribute in 48 or not. Based on https://bugzilla.mozilla.org/show_bug.cgi?id=671389, it looks like it's first shipping with FF50.
,
Aug 31 2016
Amusingly, I found a separate crash (in debug-only) when investigating this. The current implementation doesn't like `sandbox` and `upgrade-insecure-requests` together. Will fix shortly.
,
Aug 31 2016
FWIW, https://poly.nomial.co.uk/ with the sandbox directive loads without error in Firefox 51.0a1 (2016-08-31). Should a bug be filed against the Mozilla folks?
,
Aug 31 2016
So if I understand you correctly, the `sandbox` directive essentially places the document in its own origin, separate from all others? And as such it needs a CORS directive to bypass it? I notice that Firefox shows an error that the sandbox directive isn't supported, so it makes sense that Firefox behaves differently. I hadn't considered the interaction between the features. Glad to see this report at least found a different crash, though, even if it wasn't as valid as I first thought.
,
Aug 31 2016
Ok, it turns out that specifying the crossorigin attribute doesn't fix this issue, and you have to set `sandbox allow-same-origin` in the CSP header. You then don't need to specify a crossorigin attribute. Trying to set the crossorigin attribute on elements causes problems because the current document and each resource ends up with a null cross-origin (according to the console output at least) due to sandboxing, meaning that additional headers for controlling cross-origin access don't seem to apply. It looks like the sandbox essentially isolates each document absolutely and has the last word on the matter. I don't know if this is the intended behaviour, so this might need to be investigated. I've updated the config on the URL I gave to fix the problem if you want an example of a working setup.
,
Aug 31 2016
Regarding Firefox, I think so. There shouldn't be any way for a page under sandbox to access resources even if they're on the same host, assuming the allow-same-origin directive isn't set. The only question I'd have is whether Access-Control-Allow-Origin should take precedent over the CSP sandbox directive. In Chrome it doesn't appear to. I don't know whether it does in Firefox. If Firefox 51.0a1 is allowing CSP sandboxed resources to access other resources without the allow-same-origin directive set, that's certainly a bug.
,
Aug 31 2016
Filed https://bugzilla.mozilla.org/show_bug.cgi?id=1299604 on Firefox. Mike, did you want to keep this open to track the debug crash you're fixing, or do you want to resolve Won't Fix as the original issue is WAI?
,
Sep 1 2016
I'll file a new bug, let's close this out. Thanks for the report! |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by elawrence@chromium.org
, Aug 31 2016Labels: -Restrict-View-SecurityTeam Pri-2
Status: Untriaged (was: Unconfirmed)
Summary: Subresource Integrity incorrectly requires CORS for same-origin resource (was: Security: Subresource Integrity (SRI) incorrectly determines locally hosted file as requiring CORS)