Cross-origin requests for secondary resources

[martinthomson]

When making a request for the secondary resource, it's not clear what the properties of this request need to look like.

We could treat this as a full CORS request with a requirement for a pre-flight. That would be devastating for latency, but we could easily reason that it is safe.

We could take something of a lassez-faire approach to this and allow all credentials. That has certain risks associated with it. Even though I've tried, but cannot find a way in which this could be abused, we would have to do a lot of analysis to determine that it truly wasn't a problem. That and I'm not certain that we need to do this. One real downside is that it would allow the secondary server to track requests across origins.

The safest and fastest option is to withhold credentials on requests to the secondary resource. It's fast, and it's safe by default.

In the end, I think that the credential-free option is safest, unless we both a) discover a need for credentials, and b) are able to convince ourselves that the costs are small and manageable.

The current draft says this:

In order to prevent any leakage of information, the GET request for
the secondary resource MUST only contain information provided by the
origin server or the secondary server itself, namely HTTP
authentication credentials ([RFC7235]) and cookies ([RFC6265]).

We probably need to be a bit clearer about this, maybe with reference to (or by copying) the bit in the fetch spec that covers withCredentials: false.

[reschke]

The current spec allows certain user credentials; for instance, if the secondary server itself has set cookies or used HTTP auth, the client would use these in subsequent requests. I understand we want to get rid of that?

In which case:

"In order to prevent any leakage of information, requests for the secondary resource MUST NOT contain any HTTP authentication credentials ([RFC7235]), cookies ([RFC6265]), or client certificates. This is similar to the XHR mode 'withCredentials=false as specified in [XHR]."

[gaperik]

Hi,
This seem to me to be a trade-off between RTT and allowing for credentials to be used, e.g. for the purpose of access control. The extra RTT is in some situations a potential problem, especially given how CORS is designed currently (pre-flight for every request, right?).

But CORS is developing and not sure we should design the OOB mechanism to adapt to how current CORS is designed. And even if it does not change, not allowing for the cases where credentials of any kind is not allowed in requests to the secondary server seem too limiting to me.

Could we:

1. Allow for origin hinting preference in whether credentials should be used/allowed or not
2. Discuss CORS evolution (yeah, I know, the idea scares me as well and it is not something I propose for the fun of it but because it seem to be a real reason for it).
   Would it for example be possible to restrict pre-flight to primary request under certain circumstances?

[reschke]

Idea: define a media type for the payload returned by the secondary server, such as "application/oob-blob". Require OOB processing to check for that media type and abort for any content not having it. That would protect any content that doesn't happen to be coming from a cache server.

[reschke]

TODO: understand the actual requirements for sending any information beyond the URI to the secondary server (auth? accounting?)

[gaperik]

Mike B's issue concerning tokens is one use case I believe.

[gaperik]

Custom CH's from SW using JS API to OOB in browser http layer?

[gloinul]

I think Julian's idea above works fine to address the issue of my enterprise resource stealing issue.

I don't however see how it addresses the question of authority to request from the secondary server for the cases where the secondary server is providing OOB payload responses. So Mike B's case I think is very relevant for the CDN deployment case. This as the customer of the CDN do likely pay for its usage. In the proxy or self delegation case where it is likely no cost associated with serving content from the secondary to the client there is less of an issue. However for the self delegation case, like a home gateway, there might actually be very good reasons from privacy perspective to not allow non-authorized clients to request resources. The privacy issue I see there is that an attacker can prod the home gateway cache after cache hits to determine what content that is cached and thus likely watched in the home.

So from my perspective we need to look more into what support for authorization that is needed in the secondary server.

[reschke]

See EricssonResearch/Blind-Cache-Drafts@a2701cd