W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2009

Re: [cors] origin and redirects

From: Mark S. Miller <erights@google.com>
Date: Tue, 16 Jun 2009 09:12:14 -0700
Message-ID: <4d2fac900906160912r38f69f03ue85a1fdb5439c431@mail.gmail.com>
To: Anne van Kesteren <annevk@opera.com>
Cc: WebApps WG <public-webapps@w3.org>
On Tue, Jun 16, 2009 at 8:05 AM, Anne van Kesteren <annevk@opera.com> wrote:

>
> This creates some related issues we have to sort out one way or another:
>
>  A) How does this affect Access-Control-Allow-Origin?
>
>  B) How does this affect the preflight result cache?
>

I am very glad that the current cors document explains recommended server
behavior. Any enhancement, changes, or alternatives to cors should follow
this example. If the Origin header expands to carry a list of origins, then
we should update the cors recommended server behavior to account for this.
Only then can we evaluate what new vulnerabilities we create by adding yet
more epicycles. If we cannot write down a coherent recommendation for how
servers should make use of this new information, then we should not propose
to provide this new information.

If cors is indeed on a path to recapitulate the Java stack introspection
architecture as Tyler alleges, I would expect the first recommendation to
be:

     Check every origin in the set against the resource's ACL. Only if the
ACL allows this access for all origins in the set, then the access is
allowed.

IIRC, this recapitulates something like Java 1.1 or so. If this is indeed
the cors path, the next step on this path would be to allow the redirections
to provide additional access control advice, and for the recommended ACL
check at the server to treat the list no longer as a set but rather in an
order dependent manner, where some of this access control advice cuts off
the search farther back in the stack. But perhaps the constraints are
different leading to a different trajectory?

-- 
   Cheers,
   --MarkM
Received on Tuesday, 16 June 2009 16:12:50 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:31 GMT