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: 
 <CAOHkvcNutCimOggckR3ivc2=DCAP1ZhPTC2XpnP1o_E82_Pvaw@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>
Date: Tue, 2 Aug 2011 16:50:02 -0700
Message-ID: 
 <CA+5KyPR56FpKXiQ6Zyxu0V2jwaKbOghbTZyJ10Ou=YXyyk6zhA@mail.gmail.com>
Subject: Re: to CouchApp or not to CouchApp
From: Gregor Martynus <gregor@martynus.net>
To: user@couchdb.apache.org
Content-Type: multipart/alternative; boundary=000e0cd2916e03897504a98e6829

--000e0cd2916e03897504a98e6829
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Chang,

I think vhost are not meant to hide urls because of security reasons, they
are only meant to offer nice URLs.

Virtual hosts let you map domains to URLs in CouchDB but they don=E2=80=99t=
 protect
> against anyone accessing your raw CouchDB API. There=E2=80=99s at least o=
ne way
> around it that should it be sufficient to illustrate why virtual hosts ar=
e
> not a security device:


> Clients are in control of what HTTP headers they send. A malicious client
> could omit sending a Host header or simply send a valid HTTP 1.0 request
> that doesn=E2=80=99t require a Host header at all. CouchDB=E2=80=99s defa=
ult behaviour is
> for each request that doesn=E2=80=99t match any virtual host for any reas=
on, it
> behaves like a regular CouchDB instance without a virtual host defined.


Source:
http://blog.couchbase.com/whats-new-in-apache-couchdb-0-11-part-one-nice-ur=
ls


On Tue, Aug 2, 2011 at 4:47 PM, Chang Luo <chang@pokerchang.com> wrote:

> Hi Randall & Max,
> Thanks for the tips.  Do you mind providing more details for hiding _user=
s?
> Eg. if I have example.com.  How to deny public access to
> example.com/_users?
>
>
> I tried to add a rewrite rule but it has no effect.
> {
>  "from": "_users",
>  "to": "home2.htm"
> },
>
> Then I tried to add a vhost mapping and it still has no effect.
> *www.example.com/_users to website/_design/website/_rewrite*
> *or www.example.com/_users to website/_design/website/home2.htm
>
> *Max, I am new to node.js and don't know how to run audit_couchdb.  I
> installed via npm install then run "node audit_couchdb.js" and it exited
> immediately.  Do I need to specify parameters?  Does it check my local
> couchdb only?  If anyone can provide some instructions for node.js dummie=
s,
> that would be great.
>
> Thanks!
>
> Chang
> *
> *
> On Mon, Aug 1, 2011 at 3:50 PM, Max Ogden <max@maxogden.com> wrote:
>
> > for the record I am a gigantic fan of open data and love the fact that
> > anyone can get anything in my couch with one http request. if anyone pa=
id
> > for any services on maxogden.com I would lock them down using couch's
> > security model and tools like https://github.com/iriscouch/audit_couchd=
b
> >
> > On Mon, Aug 1, 2011 at 6:37 PM, Randall Leeds <randall.leeds@gmail.com
> > >wrote:
> >
> > > On Mon, Aug 1, 2011 at 14:33, Sam Kearns <sam@kearns.net.au> wrote:
> > > > I'm new around here, and I realise this is a cheap shot from an
> > armchair
> > > > developer, but this issue of security keeps coming up again and aga=
in
> > and
> > > it
> > > > seems to me that the design of CouchDB is guilty of 'dumb idea #1' =
in
> > the
> > > > following article.
> > > >
> > > >
> > >
> >
> http://www.ranum.com/security/computer_security/editorials/dumb/index.htm=
l
> > > >
> > >
> > > I can understand this advice in a lot of contexts. I'm not sure it
> > > applies to CouchDB. I'm a big fan of not requiring users to set up
> > > accounts and passwords and an admin user before they can even test ou=
t
> > > the software at all. While this thread is about CouchApps, default
> > > permit makes a lot of sense in a 3-tier architecture. Sure, sure, it'=
s
> > > advisable to secure your database anyway in case a hacker manages to
> > > penetrate your network. Even then, though, imagine a PHP/SQL world
> > > where they can just search your .php scripts on your web server for
> > > the password passed to the connection. Maybe they can't drop tables,
> > > but they might be able to do a lot of damage, and certainly read a
> > > whole lot of stuff. Certainly in a CouchApp-only world of CouchDB
> > > deployments a default deny might make some sense.
> > >
> > > >
> > > >
> > > > On 2/08/2011 7:17 AM, Luciano Ramalho wrote:
> > > >>
> > > >> On Mon, Aug 1, 2011 at 5:19 PM, Chang Luo<chang@pokerchang.com>
> >  wrote:
> > > >>>
> > > >>> E.g. I can get all maxogden.com user email and password hash with
> > one
> > > >>> http
> > > >>> call.  I won't post the URL here but anyone with basic couch
> > knowledge
> > > >>> can
> > > >>> do it in 5 seconds.
> > > >>
> > > >> Indeed... Just checked it out myself.
> > > >>
> > > >>> Any solution to this problem?  Or do I have to give up CouchApp?
> > >
> > > I think if you use vhosts you can make _users inaccessible from the
> > > public domain.
> > > CouchDB authentication should still work since internally all the
> > > _session and other security/login-related things access the _users
> > > database directly over internal APIs rather than HTTP.
> > > This might prevent you from storing custom information in the _users
> > > database, but making your own user profile document that's
> > > app-specific might make more sense anyway.
> > >
> > > -Randall
> > >
> > > >>
> > > >> I am also a fan of the simple CouchApp model, but that is really n=
ot
> > > >> acceptable. Looking forward to a positive answer to your question,
> > > >> Chang!
> > > >>
> > > >
> > >
> >
>

--000e0cd2916e03897504a98e6829--