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 https://github.com/whatwg/fetch/issues/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 https://github.com/w3c/webappsec-csp/issues/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 notifications@github.com 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 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 https://github.com/whatwg/fetch/issues/687#issuecomment-379424368, 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]

Regarding tying From-Origin protections to the absence of cross-origin/site frames: this seems like it would significantly limit the utility of the mechanism, leading to most applications not being able to deploy it.

Note that developers already have a way to ensure that their document is not iframed by an untrusted origin and does not contain iframes from untrusted origins; they could set an origin-wide CSP of frame-ancestors 'self'; frame-src 'self'. It's perfectly fine to explain to them why they might want to set such a policy on their sites, but there are many scenarios where the developer might willingly iframe a trusted cross-origin/site document on a page which uses a resource that should be protected from Spectre-like attacks. I hope we wouldn't prevent developers from securing their resources in this scenario.

[annevk]

I think I'd be somewhat supportive of something like Sec-Site with same-origin/same/cross as values. Generalizing Origin would indeed undo a lot of referrer protection that I'm not super comfortable with. Making it opt-in seems nice, but that also means we cannot realistically deploy it soon, since I'd assume we'd want to wait for origin manifests to become a thing.

The cost of adding From-Origin on the other hand seems fairly low and something we could implement pretty quickly allowing particularly sensitive resources to deploy protection soonish.

[arturjanc]

Thanks, Anne -- in this case, let's leave the Sec-Site question for a separate thread and focus on From-Origin here. I like the idea and think we should do it, but there are two caveats that are worth pointing out:

1. Deploying From-Origin may be tricky in a fair number of applications because developers don't have visibility into the requesters of their resources. E.g. if they start serving From-Origin: "same" on resources that are legitimately loaded by a non-same-origin document, these loads will break in a way that's not easy to identify or predict in advance (short of first doing a study which gathers Referer values -- which isn't foolproof because of Referrer Policy and the header being stripped in many cases).
2. Unlike the request header approach, it will not protect against bugs such as CSRF, cross-origin timings, or cases where the attacker can observe the size of the response (e.g. a local-network attacker even if the traffic is over HTTPS) because the server still emits the response as usual.

Both of these are fine if we see the header as a narrowly focused Spectre mitigation for responses not covered by CORB, such as images, but I think there is still room to do more and address cross-origin leaks (and Spectre) in a more general way.

Somewhat separately, I'd also suggest making the source list syntax compatible with CSP (e.g. 'self' instead of "same", etc.)

[rniwa]

Using the same syntax as CSP sounds good.

While there are many considerations to take with respect to Spectre, why don't we start from the simplest form of the proposal?

Starting point: From-Origin response header, if set, prevents the resource with this header from being loaded in the origin not specified by the header.

Now let's define the semantics before syntax.

First off, can we all agree that this response header should apply to all resource types? HTML, CSS, images, etc...?

Can we also agree that this should affect all types of resource loads? img element, script element, sync & async XHR, fetch, etc...

Then we need to decide what it means to be loaded in a document of an origin. There are a few options here:

1. Check all ancestor frames are of the specified origins
2. Check only the origin of the document in which the resource is loaded
3. Check only the origin of the top-level document in which one of the subframes' document loads this resource
4. Check the origin of all frames in the same tab/window, and refuse to load if one of the origins don't match.

[rniwa]

Here's my take from Spectre protection standpoint.

In browsers that do support process-per-origin or process-per-frame, (1) and (2) work best. (3) requires websites to actively prevent their origin's documents from being loaded in other origin's iframes.

In browsers that don't support PPO/PPF, all these options are okay if we're aiming for the opt-in from websites depending on what changes websites can make to protect themselves. For (2) and (3), websites can prevent any of its pages to be loaded inside an untrusted document's iframe with CSP or X-Frame-Options.

(4) works best because if there was any document of an untrusted origin in the same process as the opted-in frame, all bets are off against a Spectre attack. However, (4) is only half the solution. We also need to prevent new documents of an untrusted origin from being loaded e.g. by navigating existing iframes or inserting new frames.

I don't think we want to have that kind of side-effect in the document to which these resources are loaded.

[arturjanc]

Applying to all resource types/loads sounds reasonable to me.

When it comes to what it means to be loaded from a document of a given origin, the most obvious answer seems to be (2): "check the origin of the document in which the resource is loaded", which is consistent with how other parts of the platform work (e.g. the Referer and Origin headers, window.origin, or event.origin in a postMessage all identify the location of the current document, rather than the entire ancestor chain, or set of the origins of all sibling frames.)

The reason I find (4) fairly strange is two-fold: 1) It doesn't seem necessary to have From-Origin effectively control what frames are allowed to load in a given application because developers already have that lever: Content-Security-Policy: frame-src. An application which doesn't ever need to load cross-origin frames can ensure that it's safe from Spectre if it sets frame-src, frame-ancestors and From-Origin, to 'self' on all of its responses even if From-Origin only looks at the origin of the embedding document and ignores frames.

2) Framing a resource is a choice on part of the developer. If the application loads an iframe, it generally means the developer wants the iframe to be part of her application, or otherwise she would remove it (or possibly prevent it from loading via CSP). IIUC option (4) means that developers would be required to either remove all cross-origin frames or set From-Origin to a union of the origins of frames loaded in their application, or otherwise loading From-Origin-protected resources would break. Whitelisting these external origins in From-Origin would mean that any document in these origins would now be able to execute Spectre-like attacks on the application's resources at any time, rather than just the single explicitly iframed document while the user is interacting with the application.

Basically, I don't see how this would be better than letting developers control framing via existing mechanisms and making From-Origin care only about the origin of the document loading the resource.

[youennf]

Agreed that using the origin of the document is a good step forward. Note though that it would be different from the fetch origin/origin header value in some cases. One case is cross origin redirections. The other case is data/blob iframes/workers where what could be used is the origin as computed for service workers

[csreis]

It doesn't seem necessary to have From-Origin effectively control what frames are allowed to load in a given application because developers already have that lever: Content-Security-Policy: frame-src. An application which doesn't ever need to load cross-origin frames can ensure that it's safe from Spectre if it sets frame-src, frame-ancestors and From-Origin, to 'self' on all of its responses even if From-Origin only looks at the origin of the embedding document and ignores frames.

Agreed, though there's still an assumption that other cross-site pages wouldn't end up in the same process, independent of what that application allowed via CSP and From-Origin. For example, in Chrome without Site Isolation, a cross-site page in an entirely unrelated tab might end up in the same process (e.g., if the user has many tabs open and an existing process gets reused for it). If that page had a Spectre attack, it could access the application's data despite being in an unrelated tab.

This could certainly still be prevented if browsers took process sharing into account with From-Origin (as I think is being proposed). I just didn't see it covered in the recent summaries of what browser behavior From-Origin would require. Presumably top-level navigations to pages with From-Origin headers would have to go into dedicated processes that don't get reused for other sites. Implementing that would require cross-process navigations (as @rniwa mentioned earlier), since a tab could start out on an unrestricted page and then navigate to a page with a From-Origin header. Does that sound correct?

[annevk]

Note that 1, 3, and 4 require special considerations for workers (for 2 we can just use the origin of the worker), which can make it rather complicated as they can cross tabs (though they themselves have to be same-origin with the document they're directly associated with, which helps somewhat).

[annevk]

(As for syntax, I actually think we should follow CORS and not require any quotes. It's Origin: null, not Origin: 'null'. So it follows that it's also From-Origin: same.)

[johnwilander]

It doesn't seem necessary to have From-Origin effectively control what frames are allowed to load in a given application because developers already have that lever: Content-Security-Policy: frame-src. An application which doesn't ever need to load cross-origin frames can ensure that it's safe from Spectre if it sets frame-src, frame-ancestors and From-Origin, to 'self' on all of its responses even if From-Origin only looks at the origin of the embedding document and ignores frames.

Framing a resource is a choice on part of the developer. If the application loads an iframe, it generally means the developer wants the iframe to be part of her application, or otherwise she would remove it (or possibly prevent it from loading via CSP). IIUC option (4) means that developers would be required to either remove all cross-origin frames or set From-Origin to a union of the origins of frames loaded in their application, or otherwise loading From-Origin-protected resources would break. Whitelisting these external origins in From-Origin would mean that any document in these origins would now be able to execute Spectre-like attacks on the application's resources at any time, rather than just the single explicitly iframed document while the user is interacting with the application.

(4) can provide protection if the browser doesn't have process-per-frame/process-per-origin.

If victim.com is the top frame, then yes, it can control the page's CSP. But if victim.com is an iframe, I don't think there is a way for it to tell the browser that it will only allow a particular resource load if all frames in the current web content process are from a given whitelist.

Say you have a situation like this:

     friend.com
         |
        / \
       /   \
evil.com    victim.com (CSP allows ancestor friend.com)
 iframe       iframe
                 \
                Loads sensitive image

evil.com can now Spectre the sensitive image, right? And if From-Origin only checked the ancestor tree, it would not consider evil.com's sibling iframe.

Maybe we could have a strict mode that takes all frame origins in the process into account? I haven't given it any deeper thoughts but wouldn't such a strict mode allow for pretty good UI redressing protection too? Say payments.com makes a deal with shop.com to provide a checkout iframe. It could then refuse to display its content if shop.com's checkout page is loading unknown cross-origin iframes. And that would be beneficial even under process-per-frame/process-per-origin.

[csreis]

Maybe we could have a strict mode that takes all frame origins in the process into account?

It does seem like that would be necessary (both for frames and workers in the process), though not sufficient, as you noted earlier:

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.

It does seem like you'd need some notion of marking the process as dedicated to the origin/site, so that future frames and workers from other sites aren't loaded into it.

I haven't given it any deeper thoughts but wouldn't such a strict mode allow for pretty good UI redressing protection too? Say payments.com makes a deal with shop.com to provide a checkout iframe. It could then refuse to display its content if shop.com's checkout page is loading unknown cross-origin iframes. And that would be beneficial even under process-per-frame/process-per-origin.

It might help in the case that cross-site frames are never allowed in the same page. I think it might not help if out-of-process iframes are supported, since those could still do UI redressing attacks in the same page, just from a different process. (That said, out-of-process iframes make it possible to protect a much wider range of pages from Spectre, such as those that do have semi-untrusted cross-site frames.)

[csreis]

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.

Thanks @arturjanc for mentioning these.

For this discussion, it may actually be useful to read some of the earlier research we did in that space: "App Isolation: Get the Security of Multiple Browsers with Just One" (CCS 2011) https://research.google.com/pubs/pub37198.html

That paper had some similarities to the approaches we're considering here: it was an opt-in way for sites to try to protect themselves from attacks, it involved process isolation (as well as state isolation for things like cookies and localStorage), and it was an attempt to get some of the benefits of Site Isolation (e.g., protection from compromised renderer processes) without needing out-of-process iframes.

We wouldn't need everything the paper proposes for Spectre defense (e.g., entry-point restrictions or maybe even the isolation of persistent state), but it might give some useful ways to think about how some web sites could request process isolation, and what the tradeoffs are.

[arturjanc]

@johnwilander In principle, I don't have a problem with making stricter behavior available as an opt-in.

However, I worry about a model where unrelated cross-origin frames (outside of the ancestor chain of a given document and of the document's own descendants) can directly influence a document's behavior. For example, the situation you described seems to lead to a cross-origin information leak: evil.com can now infer if a frame from victim.com is loaded anywhere in its current process by returning different From-Origin values for its resources and seeing if they render, even if it doesn't have a reference to the victim.com window or its parent. Aside from security concerns, such "action at a distance" may lead to unexpected application failures, and doesn't seem easy to test for or debug.

Putting on my web author hat, the case you're describing is certainly possible, but due to X-Frame-Options lacking fine-grained origin-based controls, the majority of applications seem to default to only allowing same-origin framing; use of frame-ancestors is still relatively sparse. So I'd expect that the number of non-CORB-protected authenticated resources loaded in documents meant to be iframed across origins is relatively small compared to what From-Origin in "mode (2)" would protect from (and, in the case you're describing, those resources would be broken in situations in which they're currently working, so I'm not particularly convinced developers would be eager to opt into this mode.)

[johnwilander]

For example, the situation you described seems to lead to a cross-origin information leak: evil.com can now infer if a frame from victim.com is loaded anywhere in its current process by returning different From-Origin values for its resources and seeing if they render, even if it doesn't have a reference to the victim.com window or its parent.

Interesting. Yes, that is an issue to consider.

Aside from security concerns, such "action at a distance" may lead to unexpected application failures, and doesn't seem easy to test for or debug.

Agreed. I'm mostly thinking of strict mode as "the big hammer" for cases where a leak is catastrophic and site breakage is tolerable.

[johnwilander]

This will probably be my first iteration, checking frame ancestors but not all frames in the process: From-Origin: same for same-origin. From-Origin: same-site for same eTLD+1.

[othermaciej]

I think checking all frames is unnecessary. For the same/same-site case, you have to trust that you won't load dangerous third-party iframes anywhere on your site. You can self-enforce this with CSP. For the case where From-Origin specifies other origins, you have to either trust them or assume it's not a Spectre defense and just for purposes like hotlinking prevention.

Another thing to think about: should From-Origin apply to no-credentials requests? Should there be a way to say "it's ok to load my resources cross-origin but not with credentials"?

[domenic]

Should there be a way to say "it's ok to load my resources cross-origin but not with credentials"?

That would be nice, and fit with the best practices promoted for CORS already for public resources: https://fetch.spec.whatwg.org/#basic-safe-cors-protocol-setup. Basically, something that makes img elements etc. play by the same rules as the more modern parts of the platform.

[annevk]

Another thing to think about: should From-Origin apply to no-credentials requests?

If you care about protecting servers where you authenticate with your IP address, then yes.

[csreis]

For the case where From-Origin specifies other origins, you have to either trust them or assume it's not a Spectre defense and just for purposes like hotlinking prevention.

For Spectre, it's not sufficient to just trust the sites that you allow to iframe your pages. Those sites also have to have Spectre defenses of their own, or else an attacker can load them in a shared process via iframes or window.open. Example attack using the names from above: 1) evil.com loads friend.com in same process (e.g., window.open). 2) friend.com loads victim.com in iframe. 3) evil.com accesses victim.com directly using Spectre.

That means that sites would have to be told to only allow embedding on sites they trust which also have effective From-Origin defenses of their own. That might be possible, though it will probably make it harder for some sites in practice.