Re: [cors] unaddressed security concerns

Hi, Maciej-

Maciej Stachowiak wrote (on 10/24/09 4:42 PM):
>
> 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
>> <mailto:schepers@w3.org>> wrote:
>>> Sorry for being dense, but why couldn't the whitehats build toy
>>> systems on  an open honeynet?
>>
>> 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.


Excellent concrete suggestions!  This is along the lines I was driving 
at, but you've articulated it much better.

If the larger security community has other suggestions for likely 
scenarios that they have concerns about, we could model those as well.


Thanks-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Received on Saturday, 24 October 2009 21:34:26 UTC