Re: [cors] unaddressed security concerns

On Mon, Oct 12, 2009 at 8:24 PM, Mark S. Miller <erights@google.com> wrote:
> Most obviously, CORS proposes ACLs, with comma separated origins
> (following an Origin: header) to be used by servers to determine
> whether to grant read/PUT/DELETE access to cross-origin resources.

The CORS spec doesn't require servers to make this determination in
this way.  In fact, for many use cases, servers must use other facts
as well when making this kind of decision.  For example, many
deployments will also consider the Cookie header when deciding how to
process the PUT/DELETE or whatever request.  Other deployments might
use secret tokens.  Still other deployments might just digitally
signed assertions in some sort of SPKI/SDSI-like system.  CORS is
agnostic as to how these determinations are made.

> The purpose of CORS is to enable accesses that was previously denied --
> exactly such cross-origin access.

The purpose of CORS is to facilitate cross-origin resource sharing.
In particular, to make it possible to share resources across origins
that were previously difficult or impossible to share.

> The purpose of the CORS-proposed
> ACLs is to enable those who have the right to edit those ACLs to
> control which accesses should be allowed and which should be denied.
> The origins serve much the same role as the principle IDs in a
> conventional ACL-based access control system.

The primary difference between CORS and a traditional ACL-based access
control system in, say, a file system is that in a file system, the
only way an administrator can control access to files is by editing
the ACLs.  Therefore, the administrator is limited to those use cases
that can be addressed securely within the ACL framework.  In the case
of CORS, the server operator can use other information, as well as the
information conveyed by the CORS protocol, to decide how to respond to
a request.  Because of this, we need only optimize CORS for the common
use case.  Those that wish to implement more advanced use cases, such
as Tyler's printing example, are free to do so and are unconstrained
by any limitations an ACL-based system might have.

> Likewise, the preflight is intended to deny PUT and DELETE access to
> servers that don't know to check the Origin: header. The purpose again
> is to allow those accesses we think should be allowed but deny those
> we think should be disallowed.

The preflight request is intended to protect legacy servers that are
unaware of the CORS protocol and are not expecting to receive
cross-origin PUT or DELETE requests.  What we think of those accesses
has little bearing on the situation.

> If this is not access control, I must ask: what do you mean by "access control"?

I'm not sure the abstract question of whether CORS is an access
control system is that meaningful.  We should concentrate on the
following questions:

1) Does CORS introduce security vulnerabilities into legacy servers
that are unaware of the CORS protocol?
2) How well does CORS support the simple use cases of cross-origin
resource sharing?
3) Does CORS prevent sophisticated developers from implementing
advanced uses cases?

Do you find CORS problematic for any of the above questions?  Do you
think we should be concerned with other questions?

Adam

Received on Tuesday, 13 October 2009 05:50:36 UTC