couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Lenz <cml...@gmx.de>
Subject Re: Futon cannot use the RESTful HTTP API
Date Wed, 17 Feb 2010 22:45:21 GMT
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/


Mime
View raw message