Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of cmlenz@gmx.de designates
 213.165.64.20 as permitted sender)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1077)
Subject: Re: Futon cannot use the RESTful HTTP API
From: Christopher Lenz <cmlenz@gmx.de>
In-Reply-To: <87bpfnbnzn.fsf@mid.deneb.enyo.de>
Date: Wed, 17 Feb 2010 23:45:21 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <3846E87A-4B3F-4E4A-987B-610D2962644C@gmx.de>
References: <87bpfz5t39.fsf@mid.deneb.enyo.de>
 <150F65D6-87CE-4C90-8242-F639F3B3B48D@apache.org>
 <87bpfnbnzn.fsf@mid.deneb.enyo.de>
To: dev@couchdb.apache.org

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?
>=20
> 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/