New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
johnwilander opened this Issue Mar 28, 2018 · 110 comments

Comments

@johnwilander

johnwilander commented Mar 28, 2018

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

This comment has been minimized.

johnwilander commented Mar 28, 2018

@jakearchibald

This comment has been minimized.

Collaborator

jakearchibald commented Mar 28, 2018

Previous discussion #365

@bzbarsky

This comment has been minimized.

bzbarsky commented Mar 28, 2018

@bzbarsky

This comment has been minimized.

bzbarsky commented Mar 28, 2018

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

This comment has been minimized.

Member

mnot commented Mar 30, 2018

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

@johnwilander

This comment has been minimized.

johnwilander commented Mar 30, 2018

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

This comment has been minimized.

csreis commented Mar 30, 2018

@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

This comment has been minimized.

johnwilander commented Mar 30, 2018

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:

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

This comment has been minimized.

Member

annevk commented Apr 3, 2018

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

This comment has been minimized.

Member

mikewest commented Apr 3, 2018

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

This comment has been minimized.

Member

annevk commented Apr 3, 2018

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

This comment has been minimized.

Member

mikewest commented Apr 3, 2018

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

This comment has been minimized.

abarth commented Apr 3, 2018

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

This comment has been minimized.

rniwa commented Apr 4, 2018

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

This comment has been minimized.

Member

mikewest commented Apr 4, 2018

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

This comment has been minimized.

rniwa commented Apr 5, 2018

  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

This comment has been minimized.

Member

mikewest commented Apr 5, 2018

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

This comment has been minimized.

Member

annevk commented Apr 5, 2018

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

@rniwa

This comment has been minimized.

rniwa commented Apr 5, 2018

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

This comment has been minimized.

rniwa commented Apr 5, 2018

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

This comment has been minimized.

johnwilander commented Apr 6, 2018

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

This comment has been minimized.

arturjanc commented Apr 7, 2018

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

This comment has been minimized.

rniwa commented Apr 7, 2018

@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

This comment has been minimized.

Contributor

anforowicz commented Apr 7, 2018

@annevk

This comment has been minimized.

Member

annevk commented Apr 7, 2018

@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

This comment has been minimized.

johnwilander commented Apr 7, 2018

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 comment has been minimized.

Member

annevk commented Apr 7, 2018

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

This comment has been minimized.

Collaborator

youennf commented Apr 7, 2018

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

This comment has been minimized.

Collaborator

youennf commented Apr 7, 2018

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

This comment has been minimized.

arturjanc commented Apr 8, 2018

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

This comment has been minimized.

arturjanc commented May 30, 2018

I hear your concern, but there are two subtleties worth pointing out:

  1. HSTS only helps here if you set it with includeSubDomains -- otherwise an attacker can pick an arbitrary non-existent subdomain and get same-site access to the HTTPS application they want to attack. A large number of sites using HSTS do not set includeSubdomains (at first glance: HSTS on google.com, apple.com, mozilla.org, and microsoft.com does not have it, and neither do 3 of my favorite banks even though they all use HSTS). Perhaps Chrome has telemetry to disprove this in case it's just my sampling bias?
  2. Not having HSTS certainly exposes you to some attacks -- e.g. SSL stripping, leaking non-Secure cookies -- but in general HTTP content does not receive special privileges to access HTTPS data served from the same site/domain. This is both because the usual SOP restrictions consider these to be distinct origins (obviously), and because security features only expose keywords to specify a same-origin relationship (e.g. X-Frame-Options: SAMEORIGIN or CSP 'self') and require explicit opt-in to all interactions with insecure content (e.g. if an HTTPS application wants to allow interactions from HTTP via postMessage or CORS it has to directly safelist the http: URL).

I'm worried about creating a situation where insecurely delivered same-domain content will start getting special privileges to access data delivered over HTTPS -- it will make same-site interactions unsafe by default (unless they are coupled with site-wide enforcement of HTTPS, which is still rare).

@annevk

This comment has been minimized.

Member

annevk commented May 31, 2018

I think that's a pretty good argument for also comparing the scheme. @youennf @johnwilander?

@johnwilander

This comment has been minimized.

johnwilander commented May 31, 2018

Including scheme or not in Same-Site is a tradeoff. Let me explain.

Attack target: Authenticated resources on https://bank.example

Attack scenarios:

  1. The victim is logged into https://bank.example and is phished. https://phishing.example pulls in https://bank.example resources to spectre them.
  2. The victim is logged into https://bank.example and bank.example is neither on the HSTS preload list nor in the HSTS cache. Further, the victim is on an untrusted network and the attacker is in a privileged network position. Last but not least, the victim either loads http://bank.example (types it into the URL bar) or loads http://blog.example and the attacker redirects it to http://bank.example (unlikely that the victim stays there when wanting to go to the blog, but still). The attacker captures the plaintext load of bank.example and responds with a mock of the bank site which pulls in https://bank.example resources to spectre them. In this scenario the attacker already has access to all non-secure cookies and the full UI of the bank. If the victim is willing to use this rogue bank page, it's game over. So we have to assume that the victim doesn't use, maybe doesn't even see the rogue bank page, for spectre to be something the attacker needs to do. I believe this also goes for a cache poison attack where the victim would load the cached, rogue bank page later. If that page is ever used under the assumption that it's real, Spectre is not our main worry.

OK, to defend against Spectre attacks, the bank wants to use Cross-Origin-Resource-Policy (formerly From-Origin).

If Cross-Origin-Resource-Policy: Same-Site ignores scheme, the second attack scenario is still possible whereas if Cross-Origin-Resource-Policy: Same-Site does consider scheme, both attack scenarios are covered.

However, including scheme makes Cross-Origin-Resource-Policy: Same-Site into a passive mixed content blocker. All legacy calls to images from http://*.bank.example will be blocked if the bank's servers always respond with Cross-Origin-Resource-Policy: Same-Site. This will make the bank less likely to deploy Cross-Origin-Resource-Policy which means both attack scenarios are possible.

On intranets, man-in-the-middle attacks are not likely but old crufty http images are. We specifically want Cross-Origin-Resource-Policy to be a protection against Spectre attacks from open websites that pull in intranet resources.

@annevk

This comment has been minimized.

Member

annevk commented Jun 1, 2018

Nit: it's same-site, case-sensitive, at least as currently proposed.

The attack can be a little more hidden. The attacker could rewrite the contents of blog.example to include a hidden iframe for bank.example and launch the attack from there while the user is reading blog.example (or they could rely on the user not noticing the address bar change and include the contents of blog.example on bank.example).

It's a fair point that it makes adoption and HTTPS migration trickier though.

@johnwilander

This comment has been minimized.

johnwilander commented Jun 1, 2018

I keep forgetting we no longer check the ancestor tree for Cross-Origin-Resource-Policy. Otherwise the sneaky, injected iframe would not have worked.

Just so that I have it stated here, I personally think we’ve step by step drifted away from a simple one-stop-shop protection we can evangelize to the long tail of sites during the year(s) where we figure out process isolation.

My initial implementation covered all resource types, all schemes and ports in one directive, and checked the ancestor tree. Such a header has a high likelihood of protection with low likelihood of misunderstandings or breakage IMHO.

Now developers need to understand non-CORS requests and deploy Origin checks, CSP frame-ancestors and Cross-Origin-Resource-Policy to protect all their resources. The same-site concept is only available in one of the three, increasing the likelihood of overlap, gaps, and inconsistent deployment.

I’m a little sad we ended up here. It feels like we’re piling on complexity where we should strive for simplicity.

Sorry for the rant.

@youennf

This comment has been minimized.

Collaborator

youennf commented Jun 1, 2018

I am not sure what is the easiest migration path. In the long run, I guess that both HSTS includeSubDomains and migration from HTTP to HTTPS resources will happen.

Since CORP: same-site derives from same-site cookies, what is same-site cookies doing in this particular case?

@youennf

This comment has been minimized.

Collaborator

youennf commented Jun 2, 2018

AIUI, same-site cookies is not checking the scheme.
If we summarize, the ideal same-site behavior would be:

  1. Fail CORP same-site check in case of a HTTPS resource fetched from an HTTP context.
  2. Succeed CORP same-site check in case of a HTTP resource fetched from an HTTPS context.
@annevk

This comment has been minimized.

Member

annevk commented Jun 4, 2018

@johnwilander the main reason I favor and I think we went with non-granular here is that all-encompassing solutions have a poor adoption rate due the complexity the overall web has reached. This is indeed unfortunate and it is forcing smaller sites to use some kind of abstraction, but adding something that does not work for many sites is not great either.

@youennf it's hard to compare with cookies since individual cookies have ways to limit themselves to HTTPS. document.domain basically does not work cross-scheme due to Mixed Content blocking. WebAuthn is limited to secure contexts.

As for the ideal behavior, the main problem with that is that if you try to migrate to HTTPS and were already using this header you now either need to remove this header or move cdn.example.com and example.com to HTTPS at the same time. (Or as @arturjanc suggests we add the same-scheme restrictions and also allow origins as values now and you could safelist http://example.com for a limited time while you migrate to HTTPS.)

@annevk

This comment has been minimized.

Member

annevk commented Jun 4, 2018

@johnwilander the other thing I wanted to touch on, is that there's nothing stopping us from supporting a same-site value for Access-Control-Allow-Origin. There are some people not comfortable with increasing our reliance on the Public Suffix List, but it seems we keep breaching that dam anyway. But let's track that as a separate issue.

@annevk

This comment has been minimized.

Member

annevk commented Jun 7, 2018

I plan on landing #733 (and tests) somewhere next week with no further changes (no scheme or port restrictions as per above discussion). I'll also look into adding more tests to cover the syntax particulars.

The current syntax might mean we cannot turn it into a structured header in the future (see httpwg/http-extensions#629 for ongoing discussion), but it shares enough similarity with the syntax of CORS headers that I think we can have a shared parser regardless.

Now would be a good time for final appeals, though I’d be happy if we can call v1 done. 😊

@annevk annevk changed the title from From-Origin to Cross-Origin-Resource-Policy (was: From-Origin) Jun 7, 2018

@youennf

This comment has been minimized.

Collaborator

youennf commented Jun 7, 2018

LGTM to have this as v1.
I think we can continue the two items that are under discussion as follow-up issues.
Here is my personal thinking on the these two items.

  1. Add a list of origins in addition to same-origin and same-site
    This seems fine as long as it stays very simple, meaning simple string matching like done for ACAO for each origin.
    Maybe same-site+a list of origins is something we could consider too, I am not sure.

  2. Scheme checking for same-site
    A no-cors HTTP resource loaded from an HTTPS context might remain popular and there are already ways to fix related security issues. It seems good to have CORP/same-site allowing it.
    A no-cors HTTPS resource loaded from an HTTP context might not be as popular now and seems harmful, even in the long run. Maybe we can try disallowing this case.

@johnwilander

This comment has been minimized.

johnwilander commented Jun 7, 2018

Scheme checking for same-site
A no-cors HTTP resource loaded from an HTTPS context might remain popular and there are already ways to fix related security issues. It seems good to have CORP/same-site allowing it.
A no-cors HTTPS resource loaded from an HTTP context might not be as popular now and seems harmful, even in the long run. Maybe we can try disallowing this case.

I agree with Youenn here. The scheme-matching case that worries me the most is http images on https pages. We know it is a common scenario and we're struggling with how to evolve mixed content blocking in the same regard.

The reverse doesn't worry me as much, i.e. requiring a scheme match for https resources on an http page if the https resource says same-site. The resource is clearly more secure than the page and so its policy response should protect it from ending up in a non-secure context. The only downside I see there is increased complexity, similar to how the referrer header gets stripped in http-to-https transitions. Developers have struggled to understand that for two decades. :/

@annevk

This comment has been minimized.

Member

annevk commented Jun 8, 2018

I was worried that might make it harder to transition to HTTPS, but since it's only same-origin/same-site that concern is likely overblown a bit. I'll write a test for that and update the standard PR accordingly.

I filed #760 on origin values.

annevk added a commit that referenced this issue Jun 8, 2018

Define Cross-Origin-Resource-Policy response header
This header makes it easier for sites to block unwanted "no-cors"
cross-origin requests.

Tests:

* web-platform-tests/wpt#11171
* web-platform-tests/wpt#11427
* web-platform-tests/wpt#11428

Follow-up: #760.

Fixes #687.
@annevk

This comment has been minimized.

Member

annevk commented Jun 8, 2018

Done, #687 (comment) is still in effect, except that there is now a scheme restriction in one direction. I'd appreciate review on the added text and the new tests.

@arturjanc arturjanc referenced this issue Jun 14, 2018

Open

`sec-metadata` #280

3 of 5 tasks complete
@arturjanc

This comment has been minimized.

arturjanc commented Jun 15, 2018

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.

@annevk annevk closed this in #733 Jun 18, 2018

annevk added a commit that referenced this issue Jun 18, 2018

Define Cross-Origin-Resource-Policy response header
This header makes it easier for sites to block unwanted "no-cors"
cross-origin requests.

Tests:

* web-platform-tests/wpt#11171
* web-platform-tests/wpt#11427
* web-platform-tests/wpt#11428

Follow-up: #760 & #767.

Fixes #687.

Malvoz added a commit to Malvoz/sec-metadata that referenced this issue Jul 24, 2018

Change "From-Origin" to "Cross-Origin-Resource-P..
Changed "From-Origin" to "Cross-Origin-Resource-Policy" and its link destination from: whatwg/fetch#687 to its specification.

Also thought it would be nice to link to the bikeshed issue.

mikewest added a commit to mikewest/sec-metadata that referenced this issue Jul 25, 2018

Change "From-Origin" to "Cross-Origin-Resource-P.. (#3)
Changed "From-Origin" to "Cross-Origin-Resource-Policy" and its link destination from: whatwg/fetch#687 to its specification.

Also thought it would be nice to link to the bikeshed issue.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment