Re: [AC] Helping server admins not making mistakes

On 2008-06-12 14:10:56 -0700, Jonas Sicking wrote:

> My concern with the current spec is that once a server in the
> pre-flight request has opted in to the Access-Control spec, it is
> not going to be able to "correctly" handle all the possible
> requests that are enabled by the opt-in. With "correctly" here
> defined as what the server operator had in mind when opting in.

I share that concern, and I think that your Range example (while
demonstrating the danger of a particularly stupid hypothetical
implementations) in fact illustrates two very real dangers of the
current model:

 - for XML content, the authorization can be triggered by the
   content, and can't be filtered on the HTTP level
 
 - quite generally, the fact that we are moving toward a model with
   relatively complex messaging from the server to the client means
   that server-side filtering is more difficult (and therefore
   error-prone than it needs to be).  The fact that we put the
   default enforcement point on the client (despite the
   *possibility* for server-side enforcement) means that, for many
   web applications, the same code paths that confuse GET and FOOBAR
   in existing web applications will get exercised for serving the
   policies, e.g. in response to a preflight check.  Additionally,
   other weird behavior (such as unknown headers) might further be
   used to cause a badly written web application to send data to the
   client that is then interpreted as an authorization -- even when
   that wasn't intended by the application author at all.

Therefore, I'd propose two additional requirements:

   Servers should be able to easily recognize and handle cross-site
   requests by inspecting HTTP requests, without having to
   manipulate the HTTP response they send.
   
   Servers should be able to easily recognize and handle any
   authorization data that are sent back to the client, by only
   inspecting HTTP response headers.

Put differently, I'd like to be able to implement the server side of
all of this as a separate module or in an HTTP proxy.

The second requirement above rules out the processing instruction.
Let's get rid of it.

Both requirements together mandate two things:

- Extreme simplicity.

- Making information about the party that causes the cross-domain
  request to occur available to the server.
  
Now, I don't think the current model is all bad -- as has been
discussed ad nauseam, some policy enforcement *must* happen on the
client, that's inevitable.

However, I'd like to look again at a simpler model:

- Let's keep most of the processing model (including the pre-flight
  check), and let's keep the Origin header.

- Let's throw away the policy language.  Instead, let's add a single
  header to the HTTP Response:

  Authorize-XDomain-Origin: http://.....
  
  That header can carry a single origin, nothing else.

In terms of processing model changes, read access would only be
permitted if the origin of the request matches the origin of that
response header.

Pre-flight checks would only succeed if the origin of the request
matches the origin of that response header. against 

To deal with different policies for different origins, send
different answers depedingn on the HTTP request's origin header. Use
"Vary: Origin" to control cache behavior.

The main benefit of this approach is that there is a single response
header that would have to be checked in an HTTP response filter, in
order to exclude weird server-side processing from enabling bad
client-side behavior.  A paranoid site could even perform the
comparison of Origin and Authorize-XDomain-Origin headers in a
firewall, and (paranoidly) replace responses to unauthorized
cross-domai requests with a 403 -- without having to implement the
entire policy language.

My preference would be to not differentiate by method in the
client-side decisions, but force the server to do that --
preferably, in fact, by way of a dedicated Web server module that
can live outside the web application proper, and has a configuration
setup that fails safely.  (Yeah, I know, dream on. *sigh*)

If people here think that a differentiation by method is really
called for, then the model I'm suggesting would at least give that
differentiation the same granularity that is present for all the
other decisions; I consider that consistency a very good thing.

Thoughts?
-- 
Thomas Roessler, W3C  <tlr@w3.org>

Received on Friday, 13 June 2008 16:31:07 UTC