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 <[email protected]
<mailto:[email protected]>> 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
