New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 2 users

Issue metadata

Status: WontFix
Owner:
Buried. Ping if important.
Closed: Sep 2016
Cc:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug



Sign in to add a comment
link

Issue 642744: Subresource Integrity incorrectly requires CORS for same-origin resource

Reported by gsuberl...@gmail.com, Aug 31 2016

Issue description

ISSUE 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.
 

Comment 1 by elawrence@chromium.org, Aug 31 2016

Cc: mkwst@chromium.org
Labels: -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)
Repros in 55.0.2845.0.

Comment 2 by elawrence@chromium.org, Aug 31 2016

Labels: -Type-Bug-Security Type-Bug

Comment 3 by mkwst@chromium.org, Aug 31 2016

Cc: jww@chromium.org
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`).

Comment 4 by mkwst@chromium.org, 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.

Comment 5 Deleted

Comment 6 by mkwst@google.com, 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.

Comment 7 by elawrence@chromium.org, 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?

Comment 8 by gsuberl...@gmail.com, 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.

Comment 9 by gsuberl...@gmail.com, 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.

Comment 10 by gsuberl...@gmail.com, 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.

Comment 11 by elawrence@chromium.org, Aug 31 2016

Cc: -mkwst@chromium.org
Owner: mkwst@chromium.org
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?

Comment 12 by mkwst@chromium.org, Sep 1 2016

Status: WontFix (was: Untriaged)
I'll file a new bug, let's close this out.

Thanks for the report!

Sign in to add a comment