Cross-Origin-Resource-Policy (was: From-Origin)

[johnwilander]

Websites should have an explicit way to restrict any kind of cross-origin load to protect themselves against Spectre attacks. Content such as images, video, and audio may be sensitive and websites may be protected solely by virtue of their network position (inside a firewall), relying on the same-origin policy to protect against exfiltration.

There's a previous proposal from 2012 called the From-Origin header that we'd like to resurrect. With it, a server can send a From-Origin : same header on responses it wants to protect from Spectre attacks. Here's a snippet from the currently inactive proposal:

The From-Origin header can be used to restrict embedding of a resource to only certain origins. When used it must match the following ABNF:

From-Origin = "From-Origin" ":" #(serialized-origin | "same")

Cross-Origin Read Blocking (CORB) automatically protects against Spectre attacks that load cross-origin, cross-type HTML, XML, and JSON resources, and is based on the browser’s ability to distinguish resource types. We think CORB is a good idea. From-Origin would offer servers an opt-in protection beyond CORB.

In addition to the original proposal, we might want to offer servers a way to say cross-origin requests are OK within the same eTLD+1, e.g. the server may want to say that cross-origin subresources from cdn.example.com may be loaded from *.example.com without listing all those origins.

[johnwilander]

Ping @whatwg/security.

[jakearchibald]

Previous discussion #365

[bzbarsky]

@mystor @ehsan

[bzbarsky]

This might be OK to add as a stopgap, as long as we're clear that it doesn't actually solve the problem in general. We generally want a safe-by-default solution, not one that requires every single server to opt in...

[mnot]

Just to be clear - this is scoped to the response it occurs within, correct?

[johnwilander]

Yes. It is not stateful. The security benefit is that the browser can cancel the load and not bring the payload or meta data into the process where JavaScript is executed.

[csreis]

@johnwilander: Thanks, this does seem like a good fit for CORB, giving web sites a way to opt in to protection on arbitrary resources (not just HTML, XML, and JSON, though it would be a good failsafe for those as well).

@bzbarsky: I agree that both CORB and From-Origin only protect a subset of resources-- the largest we could come up with while preserving compatibility, plus anything sites choose to label with From-Origin. I agree with you that a secure-by-default solution would be preferable, but I'm not yet aware of one that can be easily deployed, at least in the short term. (For example, the idea of using credential-less requests for all subresource requests doesn't seem web compatible.) Happy to discuss options there.

I do think it's worth pursuing CORB and From-Origin at least as a stop-gap in the short term, since there's a fairly pressing need to get protection out there for as many resources as we can.

[johnwilander]

Let's discuss the subdomain aspect of this.

We'd like servers to be able to express that all pages from the same eTLD+1 are allowed to load the resource. The 2012 proposal as it stands requires the server to list all allowed domains which is error prone and uses up bytes on the wire.

Instead of having a resource on example.com send a response header like this:
From-Origin: cdn1.example.com, cd2.example.com, www.example.com, secure.example.com, example.com, many.sub.domains.of.example.com
... it could send something like this:
From-Origin: SamePrimary
... which would match example.com and any chain of subdomains of example.com. WebKit often refers to eTLD+1 as the partition.

There are at least two pieces of prior art here, none of which seem to fit our needs:

• HSTS includeSubdomains which tells the browser to include subdomains of the current host in the policy.
• SameSite Cookies which imply that the hosts should match.

To further complicate things, eTLD+1 has many names:

• eTLD+1
• Partition
• Public Suffix+1
• Primary Domain
• High Level Domain
• Top Privately-Owned Domain

Some naming ideas:

• From-Origin : SamePartition
• From-Origin : SamePrimary
• From-Origin : SamePrimaryDomain
• From-Origin : SameTPOD
• From-Origin : SameETLD+1
• From-Origin : SameETLDPlus1
• From-Origin : SameETLDPlusOne
• From-Origin : SamePublicSuffixPlus1
• From-Origin : SamePublicSuffixPlusOne

[annevk]

Chrome and Firefox efforts seem to call that boundary "site", which is also reasonably understandable. So to add to your bikeshed, I'd argue for From-Origin: same-site.

The other thing we need to make concrete is for which responses this applies. Pretty much everything but top-level navigations? (For bonus points, would it apply to OSCP? See also #530.)

[mikewest]

Something in this space seems like a good idea, so I'm supportive of the general direction.

I wonder, though, whether it would be simpler to build on existing primitives rather than add a new header. For example: what if we started sending an Origin header with every request? Presumably, servers that would opt-into sending a From-Origin header would also be capable of blocking requests with unexpected Origin headers before passing the requests on to applications that might be damaged? (FWIW, I've also been toying around with the idea of sending a lower-granularity Origin header as part of some future authentication primitive, which would boil down to an enum of cross-site/same-site/same-origin).

From-Origin is potentially simpler to deploy for some endpoints that expect same-site usage, but always sending an indication of a request's provenance gives servers a lot of flexibility in how they deal with incoming requests. Since they're already dealing with that header for access control in general, relying upon it more broadly might be less overhead than creating a new primitive for the same purpose.

To further complicate things, eTLD+1 has many names:

On this point in particular, I'd suggest that we'd be well-served to follow the PSL's "registered domain"/"registrable domain" terminology, or to follow the "site" terminology that SameSite cookies defines, that Chrome's "Site Isolation" uses, etc. I don't believe the other terms listed above are as commonly used, but I'm happy to just agree on some spelling of the concept and putting it into a more easily-referencable document.

[annevk]

Pretty sure Adam Barth tried Origin on each request to combat XSRF and it's simply not web compatible. That's why we ended up with the rules for it we have today.

[mikewest]

Pretty sure Adam Barth tried Origin on each request to combat XSRF and it's simply not web compatible. That's why we ended up with the rules for it we have today.

If the objection is purely practical, perhaps @abarth could help us recall the challenges he ran into? I'd suggest that CORS is baked-into enough of the web at this point that it might be worth trying again (especially since I think there's at least tentative agreement from Firefox folks to expand Origin's coverage to include some subset of non-GET/HEAD requests).

[abarth]

I don't remember exactly, but I think the idea was to avoid request bloat. Adding bytes to every request is (or at least pre-HTTP/2.0 was) expensive, whereas scoping the extra bytes to POST made them negligible.

[rniwa]

We've explored the idea of expanding Origin header in the request as well but the challenge we face there is deployability. It's a lot easier for websites to deploy From-Origin header on all resources than checking Origin header on every resource request while keeping it compatible with old browsers that don't send this request, etc...

[mikewest]

We've explored the idea of expanding Origin header in the request as well but the challenge we face there is deployability. It's a lot easier for websites to deploy From-Origin header on all resources than checking Origin header on every resource request while keeping it compatible with old browsers that don't send this request, etc...

I think I agree that From-Origin is easier to deploy for servers, as it doesn't require much in the way of server-side logic. If we expand the scope of the Origin header, servers would need to read it, process it, and do something useful with it, which certainly takes some effort. I'd suggest that expanding the scope of Origin has the additional benefit of giving servers the tools to more broadly mitigate CSRF attacks, but I'm willing to believe that fewer folks would be interested in doing the extra work. I think it's worth experimenting with that approach, but there's no reason we couldn't do both.

I have a few detail questions:

1. @annevk suggested that this should apply to everything except top-level navigations. That misses auxiliary browsing contexts created via window.open, which I imagine are same-process in some browsers. Would we want to address that vector as well?

2. Does From-Origin: SameSite (or however we end up spelling it), walk up the ancestor tree, or do we base the check purely on the initiating origin? We've recently fixed X-Frame-Options: SAMEORIGIN to align with frame-ancestors by checking the entire tree, and I'd suggest that that's the right behavior here as well.

3. We apparently talked about this in CSP: Consider allowing frame-ancestors to work for subresource loads. w3c/webappsec-csp#17 as well. I'm less enthusiastic about adding new directives to CSP than I was in 2015, but it's worth evaluating whether we should consider this an analog to frame-ancestors by adding a new CSP directive, or if we should add a new header entirely.

4. Would we apply this to redirect responses, or just final responses? I vaguely recall differences in X-Frame-Options behavior on this point between browsers, so it's probably worth hammering out (FWIW, I'd suggest that we should apply the check to redirect responses, returning an error rather than following the redirect, as appropriate).

[rniwa]

1. I'm not certain it makes sense to prevent window.open on the basis that some browsers don't support it today.

2. We should probably match frame-ancestors.

3. I'd defer this to @johnwilander

4. Yes, we absolutely have to apply this to all redirect responses.

[mikewest]

Thanks, @rniwa!

I'm not certain it makes sense to prevent window.open on the basis that some browsers don't support it today.

If the purpose is to prevent an origin's data from entering a process, I'd suggest that we need to be as thorough as possible in reducing an attacker's opportunity. Because window.open gives the opening context a handle to the newly opened window, it gains script access to that window. Chrome's implementation only recently allowed us to push those newly opened windows into separate processes. I'd be thrilled to hear that other vendors have done the same. shrug

[annevk]

Note that the window.open() vector can be emulated via <a target=...>.

[rniwa]

WebKit is working to isolate window.open and other contexts with opener in a separate process as we speak.

Blocking them in window.open and <a target="_blank"> can be a good mitigation for a short term though. I guess the question is whether we should make that behavior optional or mandatory. Or if we should make From-Origin imply that, or add yet another header/CSP option to enforce it.

[rniwa]

Another option for window.open(~) and <a target="_blank"> is to disable nullify opener when this header / CSP option is set so that browser engines can easily put it into a different process.

[johnwilander]

We've discussed this further and have some thoughts.

Let's assume a main goal of From-Origin is to provide servers with a way to prevent their resources from being pulled into a process space where they can targeted by a Spectre attack.

Only checking the origin of the request does not suffice in the nested frame case. This means just adding Origin headers to requests is not enough, leaving aside ease of deployment.

Checking the ancestor list upward is not enough. Checking it up and down is not enough either. What is needed here is a guarantee that, at the time of the request, there is no cross-origin or non-same-site frames in the web content process. This includes sibling frames at any level.

Even with such a guarantee at the time of the request, cross-origin or non-same-site frames may be loaded into the process at a later stage and a Spectre attack could be possible. The only way we see this fully working is checking that no cross-origin or non-same-site frames are in the process at the time of the request, and blocking any subsequent cross-origin or non-same-site frame loads into the process.

What do you think?

(We might start with the simple version of just checking against the origin of the request.)

[arturjanc]

John, I'm not sure I follow the frame-focused reasoning in your proposal; IIUC under this logic evil.com could not have any frames but still load victim.com/secret.txt as an <img> or another subresource type, which would then allow it to exfiltrate its contents. Or am I misunderstanding the approach?

Wouldn't the real solution for Spectre-like exfiltration be to have something like https://www.chromium.org/developers/design-documents/oop-iframes?

[rniwa]

@arturjanc: The idea here is that img, script, etc... won't be able to load these resources if From-Orign doesn't allow it. In other words, From-Origin basically removes non-CORS cross-origin resource loading.

[anforowicz]

On Fri, Apr 6, 2018 at 7:00 PM, arturjanc ***@***.***> wrote: John, I'm not sure I follow the frame-focused reasoning in your proposal; IIUC under this logic evil.com could not have any frames but still load victim.com/secret.txt as an <img> or another subresource type, which would then allow it to exfiltrate its contents. Or am I misunderstanding the approach? I assume that victim.com/secret.txt would be served with a response

header like "From-Origin: https://victim.com" and therefore the browser would prevent this resource from being loaded into the renderer process hosting evil.com (i.e. the browser would stop the load unless it can guarantee that the target renderer only hosts data from the https://victim.com origin).

Wouldn't the real solution from Spectre-like exfiltration be to have something like https://www.chromium.org/developers/design-documents/ oop-iframes?

Different browsers can approach the "can guarantee that the target renderer only hosts data from the https://victim.com origin" problem in different ways. Current plan of action for Chromium is to use out-of-process iframes, but even without oop-iframes a browser can track which origins/sites are hosted in a renderer process and block resource loads / frame embedding as needed (possibly in a way that breaks legacy users of resource marked this way - this is why mechanisms like "From-Origin: ..." or "X-Frame-Options: SAMEORIGIN" are needed as an opt-in mechanism).

…

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#687 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ALoIqKSQiKNZll_5WY9NCVpigi-Kr-Qzks5tmB29gaJpZM4S--lq> .

[annevk]

@johnwilander does that mean you're not doing out-of-process <iframe>? In any event, what you're saying there sounds like a totally different thing from From-Origin. If you want it affect more than just the response it's on it'd be good to have a new name for that proposal, to keep them somewhat separate.

[johnwilander]

Maybe all browsers will ship process-per-origin, on by default, in a month, but I doubt it. :) Maybe all browsers will be fine spinning up ~70 processes to load a news page, but I doubt it.

If I’m right, we need an interim solution for sensitive resources. Hence, CORB and this From-Origin thread. Once all browsers do process-per-origin by default, this header will not be needed for Spectre protection but may still me useful to ensure that no third parties are involved in this resource load.

[annevk]

This header is useful even with process-per-origin/site, since the whole point is preventing yourself from ending up as a no-cors resource in an attacker origin. Process-per-origin/site wouldn't help with that. That's what I thought we were going for. If we want to go beyond that, we should probably discuss requirements again, since it's not entirely clear to me what this is going to help with then and how.

[youennf]

I think john's comment is related to:

Does From-Origin: SameSite (or however we end up spelling it), walk up the ancestor tree, or do we base the check purely on the initiating origin? We've recently fixed X-Frame-Options: SAMEORIGIN to align with frame-ancestors by checking the entire tree, and I'd suggest that that's the right behavior here as well.

My understanding is that the simple check on the initiating origin is probably good enough but I may be overlooking things here.
AIUI, there might be some attacks whenever there is any cross-origin iframe loaded in the same process, at the time of the load or after the load.
Going through the ancestor tree or even through the list of frames in a process will not give a full protection.
And I am not sure this will be useful at all in case of out-of-process iframes.

[youennf]

And I am not sure this will be useful at all in case of out-of-process iframes.

Not useful for specter, question is whether it is useful for other kinds of attacks.

[arturjanc]

I've been following this thread while on vacation and didn't have time to comment until now, but this is an important problem that I also feel strongly about solving (thank you @johnwilander for starting this discussion!). Since there are a lot of ideas here, I wanted to summarize the discussion as I understand it, and compare the benefits of the proposals that came up.

As background, in the past we've thought a fair amount about protecting applications from cross-origin information leaks -- allowing developers to prevent their applications' endpoints from being loaded as subresources of an attacker-controlled document goes far beyond protecting the exploitation of Spectre-like bugs, and can address a large number of cross-origin attacks we've seen over the past decade.

Specifically, having the browser refuse to load protected resources in the context of the attacker's origin/process, could help solve the following classes of issues: cross-site script inclusion (XSSI), cross-site search, CSS-based exfiltration, as well as Spectre. Telling the server about the requester's origin as Mike suggested above would also give developers the chance to prevent most kinds of attacks based on cross-origin timings and CSRF -- the server could be configured to only accept subresource requests coming from trusted origins.

For completeness, addressing these kinds of issues was part of the motivation for EPR and Isolate-Me, as well as for same-site cookies. But these proposals are fairly heavy-weight to implement and adopt, and there is value in having a simpler mechanism to tackle the classes of issues mentioned above.

IIUC the discussion here focused on two main alternatives:

1. The From-Origin response header as outlined in Anne's original proposal which would prevent the browser from exposing the contents of the response to non-safelisted origins.
2. Adding a request header to subresource requests, which would allow servers to decide what to do with the request depending on its source.

The first option is somewhat simpler and makes the protection more explicit; in some cases, developers might be able to set From-Origin: same on all responses and that would be sufficient to protect against Spectre and some cross-origin leaks. The second option requires more work on part of the server (adding logic to decide whether to respond to a request based on its sender), but it's more flexible and more powerful because it can also protect against CSRF and timing attacks, though with some caveats.

As a data point from someone who works with a large number of non-trivial applications, I feel that it might be somewhat easier to adopt this if we go with option 2, possibly with a new request header, e.g. Sec-Requesting-Origin -- we might not be able to reuse Origin because of backwards compatibility issues, though I'm not 100% sure about this. On the server side, the logic would boil down to checking if the header is present in the request, and if so, rejecting requests if the requesting origin isn't trusted (if there is no header, or the origin is trusted, return the response as usual).

If browsers were to consistently set this header, developers could start by collecting data about origins which are already requesting authenticated resources from their application by collecting header values, and then turn on enforcement by returning empty responses if the requesting origin isn't trusted. This could also work even if there is a Referrer Policy of no-referrer if we make the user-agent send a special identifier to include some coarse-grained information about the source (e.g. same-origin, same-site or cross-site as Mike suggested above). If we're worried about the number of bytes on the wire this would add to requests, it could be require an opt-in via an Origin Manifest or a header-based mechanisms similar to HSTS. Finally, we could also consider having a special way to annotate navigational requests to protect against the exploitation of CSRF via top-level navigations.

I think this would be powerful enough to allow application developers to protect from Spectre, especially if combined with default protections via CORB, and would simultaneously allow developers to protect against other cross-origin leaks. From-Origin as originally described in Anne's doc seems workable as well, but is a little more constrained -- perhaps there really is value in doing both things?

[arturjanc]

I looked at the spec changes in #733 and they make sense to me. I also like @youennf's solution from #687 (comment) to not relax the same-site restrictions to HTTP origins when loading HTTPS resources (but allow loads in the other direction).

LGTM overall for v1. I do think some developers may encounter problems during adoption due to the lack of origin-based granularity and not having sufficient visibility into who requests their resources, but this is likely something we can tackle in the future.

[anforowicz]

I tried to find bugs tracking implementation status in various browsers and this is what I came up with:

• Chrome: https://bugs.chromium.org/p/chromium/issues/detail?id=837379 (active)
• Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1459573 (active)
• Safari: https://bugs.webkit.org/show_bug.cgi?id=184560 (fixed)

I hope that the list above is useful going forward (I wasn't able to find links to these bugs in the comments above).

I also looked at https://master-dot-wptdashboard.appspot.com/results/fetch/cross-origin-resource-policy?label=master&label=stable&aligned and I see that Safari passes most WPT tests for CORP, but is not yet at 100%. I don't know how to see details of the test results or how to locally/manually run the tests against Safari - I am not sure what the failures mean (incomplete implementation in Safari? test issues?
are these tracked in a separate bug?).

[annevk]

@anforowicz #733 (comment) has links, which include https://bugs.webkit.org/show_bug.cgi?id=186761 for Safari which was supposed to track remaining failures. Perhaps those are only in Safari Technology Preview? Or perhaps new tests landed since then.

cc @youennf

[youennf]

script-loads.html, image-loads.html and fetch-in-iframe.html are running fine locally and using w3c-test.org for me. I do not know why they are not showing up as such in WPT.

fetch.any.js seems to be buggy with regards to same-site.
It seems that fetch.any.serviceworker.html is run over HTTPS while fetch.any.html is run over HTTP on w3c-test.org, which has an impact on same-site behavior.

I'll do a PR.

[youennf]

Uploaded web-platform-tests/wpt#14907

[larsonreever]

There are already extensions that e.g. disable X-Frame-Options; I worry that use of such would become
more widespread if CSP is seen as something that breaks the web - to no
security benefit for the user - by blocking third-party font and image loads.Only WPT failure seems to be related to case-insensitive comparison of the value. WebKit currently allows SAME-ORIGIN.
It does not seem that we have yet added tests for HTTP same origin loads from HTTPS contexts. We should probably be consistent no matter whether the load destination is Document or not.
I guess that we could either fail or return an empty response.
This seems to be a good topic to discuss in whatwg/fetch/github
Thanks
Security Advisor
@WPhH