Re: [cors] unaddressed security concerns

On Oct 24, 2009, at 10:03 AM, Adam Barth wrote:

> On Fri, Oct 23, 2009 at 10:34 PM, Doug Schepers <schepers@w3.org>  
> wrote:
>> Sorry for being dense, but why couldn't the whitehats build toy  
>> systems on
>> an open honeynet?
>
> They could, but what would we learn from such an experiment?  If they
> build only secure systems, then we'd learn that security experts can
> build secure systems, which is somewhat unsurprising.  If they build
> insecure systems, then we'd learn that it is possible to build
> insecure systems, which we know already.
>
> The real question hinges around what sorts of systems real developers
> will build given CORS as a tool and whether we can prod them into
> building more secure systems by changing the API.  There isn't really
> a way for us to answer that question in our ivory tower because it
> revolves around who writes blog posts about what, and how good the
> sample code is that people start copying and pasting.
>
> I suspect we could do much more for the security of the web by writing
> up good tutorials and example code for using CORS than we could by
> tweaking various parts of the specification at this point.

I think it would be valuable to put together a secure version of a  
simple use case. First, for tutorial value, and second, to show that  
it's possible to write a simple system that uses CORS without  
immediately creating a CSRF attack, and that you don't have to do  
anything super tricky to make it work. We don't need a hackathon  
contest to learn something from the exercise, our own analysis should  
be sufficient. Here's two potentially interesting simple scenarios:

1) Pure public data.
     a) Sever A offers a public data API at some URL - the API is  
accessed with GET and looks at the query part of the URL.
     b) The data is not user-specific, just public knowledge like a  
list of search hits or the answer to a math problem.
     c) The server opts in to public access to this data via "Access- 
Control-Allow-Origin: *" (on the URL providing the data API only).
     d) Server B accesses data via this API.

Hypothesis: this does not introduce a CSRF vulnerability on Server A.

2) Simple per-user data.
     a) Server C offers a per-user data API at some per-user URL - the  
API is accessed with GET and looks at the query part of the URL.
     b) The data is user-specific (e.g. list of contacts from an  
address book), determining what user
     c) Server C allows the user to grant access to this data to a  
specific other origin on a per-user basis.
     d) For users that have not opted in, cross-origin access to the  
data is refused (by not sending any special Access-Control headers).
     e) For users that have opted in, Server C responds to normal and  
preflight requests with Access-Control-Allow-Origin including the  
allowed other servers only, and Access-Control-Allow-Credentials.
     f) Inside the implementation of the URL, the server checks Origin  
to determine if the request should be allowed.
     g) For requests missing Origin, the server rejects the request  
(in a realistic deployment it might use a secret token mechanism to  
allow self requests in legacy browsers).
     h) For requests from an appropriate Origin but missing cookies,  
the server returns no data, just a token indicating that the user  
needs to log in to Server C.
     i) For requests from an appropriate Origin and including cookies,  
the server returns the per-user data.
     j) Server D attempts to get per-user data from Server C using XHR 
+CORS with the credential flag set.
     k) If server D gets the "need to log in" error back, it gives the  
user a link to Server C's login page.

Hypothesis: this does not introduce a CSRF vulnerability on Server C.

Perhaps we could build examples along these lines and host them on  
Google App Engine or the like. Maybe we could also make versions that  
don't opt into CORS at all, to check specifically whether the addition  
of CORS created new vulnerabilities.

Regards,
Maciej