[ 
https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13107168#comment-13107168
 ] 

Jason Smith commented on COUCHDB-431:
-------------------------------------

CORS bugs allow cross-site request forgery (XSRF) attacks--the most dangerous 
threat on the Web.

IMHO, to say "CORS is not about security" is to disqualify one from making an 
implementation.

CORS is a three-body problem:

1. Client = browser
2. Server = couch
3. Origin = site the browser is on, a tuple {protocol, hostname, port}, e.g. 
http://www.naked-ladies.com:80

The word "sharing" sounds nice and friendly. It reminds me of kindergarten. 
That word is misleading.

Attention Couch developers and administrators: naked-ladies.com and every other 
site on the Web is, even now, attacking your couch, fetching and storing data, 
and they have ALL OF YOUR USERS' session cookies.

naked-ladies.com does this by attracting visitors to their site, and sending 
Javascript to the browsers to perform their attacks for them. Your ONLY 
protection is that browsers will not (generally) query to a different domain. 
With CORS, browsers will query, but only if the couch tells them it is okay. We 
are seriously playing with fire here.

Databases are not characters in this story. Per-database CORS settings
make as much sense as per-database user accounts. Practically, syncing 
_security objects between multiple databases will be a complete nightmare. And, 
it presents a race condition where cross-origin policies are incorrect between 
DB create and _security updates.) But  what about /_session? How come 
www.origin.com can access /origins_db/ but once your session times out, it 
can't reconnect? How come it can't fetch some /_uuids?

> Support cross domain XMLHttpRequest (XHR) calls by implementing Access 
> Control spec
> -----------------------------------------------------------------------------------
>
>                 Key: COUCHDB-431
>                 URL: https://issues.apache.org/jira/browse/COUCHDB-431
>             Project: CouchDB
>          Issue Type: New Feature
>          Components: HTTP Interface
>    Affects Versions: 0.9
>            Reporter: James Burke
>            Assignee: Benoit Chesneau
>            Priority: Minor
>             Fix For: 1.2
>
>         Attachments: 0001-cors-support.-should-fix-COUCHDB-431-2.patch, 
> 0001-cors-support.-should-fix-COUCHDB-431.patch, 
> 0001-cors-support.-should-fix-COUCHDB-431.patch, 
> 0001-cors-support.-should-fix-COUCHDB-431.patch, 
> 0001-cors-support.-should-fix-COUCHDB-431.patch, 
> A_0001-Generalize-computing-the-appropriate-headers-for-any.patch, 
> A_0002-Send-server-headers-for-externals-responses.patch, 
> A_0003-Usably-correct-w3c-CORS-headers-for-valid-requests.patch, 
> A_0004-Respond-to-CORS-preflight-checks-HTTP-OPTIONS.patch, cors.html, 
> cors_test.html, test_cors2-1.tgz, test_cors2.tgz
>
>
> Historically, browsers have been restricted to making XMLHttpRequests (XHRs) 
> to the same origin (domain) as the web page making the request. However, the 
> latest browsers now support cross-domain requests by implementing the Access 
> Control spec from the W3C:
> http://dev.w3.org/2006/waf/access-control/
> In order to keep older servers safe that assume browsers only do same-domain 
> requests, the Access Control spec requires the server to opt-in to allow 
> cross domain requests by the use of special HTTP headers and supporting some 
> "pre-flight" HTTP calls.
> Why should CouchDB support this: in larger, high traffic site, it is common 
> to serve the static UI files from a separate, differently scaled server 
> complex than the data access/API server layer. Also, there are some API 
> services that are meant to be centrally hosted, but allow API consumers to 
> use the API from different domains. In these cases, the UI in the browser 
> would need to do cross domain requests to access CouchDB servers that act as 
> the API/data access server layer.
> JSONP is not enough in these cases since it is limited to GET requests, so no 
> POSTing or PUTing of documents.
> Some information from Firefox's perspective (functionality available as of 
> Firefox 3.5):
> https://developer.mozilla.org/en/HTTP_access_control
> And information on Safari/Webkit (functionality in latest WebKit and Safari 
> 4):
> http://developer.apple.com/safari/library/documentation/AppleApplications/Conceptual/SafariJSProgTopics/Articles/XHR.html
> IE 8 also uses the Access Control spec, but the requests have to go through 
> their XDomainRequest object (XDR):
> http://msdn.microsoft.com/en-us/library/cc288060%28VS.85%29.aspx
> and I thought IE8 only allowed GET or POST requests through their XDR.
> But as far as CouchDB is concerned, implementing the Access Control headers 
> should be enough, and hopefully IE 9 will allow normal xdomain requests via 
> XHR.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to