Re: XDomainRequest Integration with AC

Sunava Dutta wrote:
> In offline conversations with Jonas on the topic of supporting the url
> syntax I think Jonas mentioned a good point regarding supporting <URL>
> for the private scenario. Namely, in caching scenarios allowing the
> URL to be sent in the response header if mistakes happen (for example
> Vary by origin header is not sent or ignored) doing so will ensure
> that it fails securely. I'm not so sure about the value for the public
> data scenario (other than consistency). Here's what I came up with,
> feel free to add on or elaborate.

Just to clarify, your proposal is that when
Access-Control-Allow-Credentials *is not* set to true we should only
allow the value "*" for Access-Control-Allow-Origin? Whereas when
Access-Control-Allow-Credentials *is* set to true we already only allow
the URL syntax for Access-Control-Allow-Origin.


> Pros (of supporting URL syntax in public scenarios)
> *       Supporting URL allows for a site to return data that's related
> to a particular site, but is non user specific (no creds)

This can be accomplished either way since the server can use the Origin
header if it wants to send different data for different requesting servers.

I'm not really sure that that is a usecase that we have designed much
around though.

> Cons
> *       A better architecture here is that a site will rely on the
> Access-Control-Origin header to determine the site and then decide to
> send the data or not. Along those line it as a few teammates said it
> seems wasteful to support <URL> syntax for the public scenario as we
> don't want the data to be sent on the client and dumped. The server
> should simply not send the content if the Origin is not what is
> desired.

Please note that the header is simply called "Origin" now, and has been
for quite some time.

> *       The second problem that comes to mind is that clients cannot
> be trusted. The resource server essentially is relying on the  client
> to enforce the domain check.  However since this is anonymous access,
> the client could well be evil.com's server, which would simply ignore
> the <URL> and grab data.   The resource server has no way of telling
> who the request party really is -- it is just an anonymous HTTP
> client. This may instill a false sense of security for server
> operators.
> *       The third challenge here is that the access-control-origin
> header may be spoofable therefore this scenario is not reliably
> solved.

Like you point out, if you can't trust the client then your initial
proposal for the server to look at the Origin header does not work either.

However this seems to be the case no matter if we support the URL syntax
for public data or not. So I don't see how this is a pro or con one way
or another. All three cons you are listing seems to come down to that in
the public data scenario the client can't be trusted, which does seem
partially true.


The way I see it is this:

Pros of supporting the URL syntax for public data:
* Simpler and more consistent specification.
   I.e. the URL syntax is always allowed and we are only forbidding the
   combination of wildcarding and sending cookies at the same time.
* Allows a server which serves private and public data. When the server
   receives cookies it can customize the result for the user, when no
   cookies are sent it just sends back a generic response.
   In both cases it echoes back in the Access-Control-Allow-Origin
   response header the URL it received in the Origin request header.
* Allows mashup sites inside a corporate firewall. These servers might
   serve company private data and wants to use the Access-Control spec
   to allow the data to be mashed up. However it does not want external
   websites to load such data. It does this by only echoing back in the
   Access-Control-Allow-Origin header the URL from the Origin header
   if the Origin is an intranet server.
   In this case the client can be trusted even in the public data case
   since only browsers installed on company client desktops can issue
   requests to the site, evil.com is blocked by the firewall.

Cons of supporting the URL syntax for public data:
* There is a risk of a false sense of security. I.e. a site might send
   private data from a URI and protect it only by sending
   Access-Control-Allow-Origin: trusted.com. The spec does state that
   such a response should not be exposed to evil.com. However if evil.com
   made such a request server-to-server it can of course ignore this and
   still read the data.

A couple of notes:
The last 'con' might happen anyway if the server just looks at the
Origin request header and deciding whether to send the data or not based
on the value of that header. So for the false sense of security argument
to hold we would also be required not to send the 'Origin' header with
public data requests. Similarly the 'Referer' header should not be send
since it carries the same risk.

The second 'serves private and public data' was something that Hixie
mentioned that google might want to do in the future. If a request for
search results includes cookies identifying the user the results could
be customized for the users preferences, otherwise a generic search
result is returned.

Also note that such a server has no way of knowing if the request is
private or public. The fact that no cookies are included might simply
mean that the user doesn't currently have any cookies set for the
requested URI. So if it gets a request from example.com that doesn't
include cookies it does not know if it should send back public data with
"Access-Control-Allow-Origin: *" or with
"Access-Control-Allow-Origin: http://example.com"

> On an issue that *May* be related, section 4.3 of the latest editors
> draft says, "The Access-Control-Credentials HTTP response header
> indicates whether the response to request can be exposed when the
> credentials flag is true. When part of the response to an preflight
> request it indicates that the actual request can be made with
> credentials."
> Does this mean that credentials can only be sent in a second request
> or 'actual request' *after* a preflight request is sent *and* the
> response Access-Control-Credentials header is true? (Or can creds be
> sent without pre-flight? Pardon me if we discussed this prior and I've
> forgotten) Of course all this is assuming the credentials flag is
> true, which is the prerequisite.

It means that when the preflight request is done it never includes
cookies. It is only the "actual" request after the preflight that does
include cookies if the security checks pass.

The sentence is not about non-preflighted requests, such as GET requests
or POST requests with content type 'text/plain'.

At least I think that was the intention.

/ Jonas

Received on Friday, 1 August 2008 20:34:09 UTC