Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: 
 <CAAL6JQjbpOD9GOu-dDDf7-1-44pANT3U=ZKaNYEBXPcX11C8pA@mail.gmail.com>
References: 
 <CA+5KyPSE3BULUc7KONgx8ZqfNKW++_r8vgdhh7HLxLr0JgfM0A@mail.gmail.com>
 <CAONf+LQKjE6NVCsLKWb3wzmWOwrS2ej+_PCJS4Z=uV3hj0OtOg@mail.gmail.com>
 <CAOHkvcP0XMAFvvFhaw3azEyqBxPMhNxFwkYX+5_x52ScSaxEbg@mail.gmail.com>
 <CAMkGvyNO4GC8e+PWu8u7BpV6b4OUvXZ3v37y5kpnXdrYgn_nBA@mail.gmail.com>
 <4E371B93.8060303@kearns.net.au>
 <CAAL6JQj_u0RgDhQG95oFrQfJ3MUeRXHb+Q6d1Cc6DEBUwaE_vA@mail.gmail.com>
 <CAONf+LTt0Hmuhx8PTs_LdzzX-fHQDAhQg_kJabTQAnfnBdxZqQ@mail.gmail.com>
 <CAOHkvcNutCimOggckR3ivc2=DCAP1ZhPTC2XpnP1o_E82_Pvaw@mail.gmail.com>
 <CA+5KyPR56FpKXiQ6Zyxu0V2jwaKbOghbTZyJ10Ou=YXyyk6zhA@mail.gmail.com>
 <CAONf+LTd+qQtLBb7iXb-H_HJs4Xm+t+Bw0G4CMLCC8X=bYwdFQ@mail.gmail.com>
 <CAAL6JQhytD90Jn3f7LT-HUMVH=T5GgTEMXWzaR6kQ5BgqZGRSw@mail.gmail.com>
 <CAAL6JQjbpOD9GOu-dDDf7-1-44pANT3U=ZKaNYEBXPcX11C8pA@mail.gmail.com>
From: Jason Smith <jhs@iriscouch.com>
Date: Tue, 16 Aug 2011 07:30:43 +0700
Message-ID: 
 <CAN-3CBLheiAds-L5Vps-amEHN-F-17yRqHzbzNzAq-Ev9BKa5g@mail.gmail.com>
Subject: Re: to CouchApp or not to CouchApp
To: user@couchdb.apache.org
Content-Type: text/plain; charset=UTF-8

On Thu, Aug 4, 2011 at 4:22 AM, Randall Leeds <randall.leeds@gmail.com> wrote:
>> To add to this, when you create a vhost configuration on iriscouch, I
>> believe iriscouch actually sees that configuration change and changes
>> a downstream proxy. Submitting a request without a Host header will
>> make it so that iriscouch does not know where to route your request
>> and it returns an error.
>>
>> Now there's still the problem that if someone knows your
>> username.iriscouch.com address they can bypass that. It would be a
>> valid question for iriscouch support to ask whether that can be locked
>> down by requiring a valid user, at which point you could use vhosts
>> pretty securely.

I'm still not convinced those jokers at Iris Couch know what they are doing.

> Here I mean to say that require_valid_user=true is great for locking
> down your couch, but one might want to only lock down the raw couch
> interface and not require a valid user when going through a vhost, so
> you could still have a logged out public landing page for your
> couchapp.

Vhosts and rewrites are not pertinent to a security assessment of
CouchDB. Simplify. Simplify. Use the Couch tools to establish the
security you need. Then add vhosts and rewrites as needed by your
application. Subsequent vhost/rewrite changes will not threaten the
security situation.

Things to think about regarding CouchDB security:

* Authentication: basic, cookie, BrowserID, http vs. https
* Users
* Roles
* Database security objects
* validate_doc_update() functions in each database

I am pretty sure that is exhaustive. The best starting point to learn
about CouchDB security is the "Definitive Guide" book.

The best tool (to my knowledge) to understand what's going on is Audit
CouchDB (basically nessus for CouchDB).

    https://github.com/iriscouch/audit_couchdb

or

    npm -g install audit_couchdb
    audit_couchdb https://admin:secret@mycouch:5984

Run it and do what it says. Or check out its source code for a
detailed look at CouchDB security.

Currently Audit CouchDB only runs in NodeJS, however the major
requirement is the Node "request" module, which I recently ported to
jQuery

    https://github.com/iriscouch/request_jquery

Thus porting it to the browser should be easy. I haven't done that yet
since, for better or worse, I find myself surrounded by node binaries
:)

-- 
Iris Couch