On 17.02.2010, at 21:34, Florian Weimer wrote: >> thanks for reporting this, but I'm not I understand what's supposed to be >> going on. Can I ask you to explain in a little more detail what your concerns >> are? > > If you have an open Futon session, any web site you visit can write to > the Futon database, provided that the URL to the CouchDB instance is > known.
There is no such thing as a Futon "database" (unless something big slipped through my radar recently), and if there's a CSRF problem with CouchDB I can't see how it'd be related to Futon? Futon is just a couple of static files that have XHR access to CouchDB due to being served from the same domain. There is no server-side component to Futon that handles POST requests etc, everything goes directly to the CouchDB HTTP API. AFAICT there's no reason an attacker would want to attack through Futon rather than going directly through the API. Actually I don't even see how that would work. > This is because browsers do not prevent cross-domain POST > requests using XMLHttpRequest. Huh? I'm pretty sure they do prevent exactly that (that's the "same origin" policy). That's why people came up with XDomainRequest and "Cross-Origin Resource Sharing" etc: modern browsers do support cross-domain scripting, but only if (in this case) the CouchDB server would explicity allow it, for example by including a special HTTP header. The way CSRF attacks work in general is by means of img tags (only for GET requests) and scripted form submissions (which browsers *do* allow to go cross-domain). (AFAIK) Maybe I'm missing something here, but I'm always happy to learn new ways to wreak havoc in web applications :) > The Futon session cookie will not be > transmitted by some browsers due to the HttpOnly flag. (Regular > form-based POSTs not appear to work as the content type is not > correct.) Actually I can think of a possible attack vector here. But I'm not sure whether this list is the right place to discuss this stuff. Don't we have a security@ list? > Anyone who can write to the CouchDB instance can upload an HTML > document which contains embedded Javascript as an attachment to a > document which is reachable with a fixed URL. If a Futon user loads > this document accidentally (or loading it is forced by a malicous web > page that is displayed with an open Futon session), the Javascript > executes with full access to the database (read and write access, > including PUT etc. methods). This risk also exists if the browser > supports HttpOnly cookies. True, if people manage to upload the attachment. This risk can be lowered somewhat by serving all attachments with a "Content-Disposition: attachment" header AFAIK. But not allowing the malicious upload in the first place would be better. Cheers, -- Christopher Lenz cmlenz at gmx.de http://www.cmlenz.net/
