incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Max Ogden <...@maxogden.com>
Subject Re: to CouchApp or not to CouchApp
Date Tue, 02 Aug 2011 23:55:08 GMT
My point with vhosts and security was that if you arent exposing couch to
the world you can route requests for certain couch-hosted domains to your
couch and let vhosts limit the exposed API.

this means you need to run something like nginx in front of couch and
register couch as an nginx upstream. then when people hit your domain they
will be routed directly to the _rewrite handler and you can expose whatever
you want from there

if you expose the root api of couch over the internet there aren't built in
ways to lock down everything. the solution would be to not expose the couch
root api.

for audit-couchdb usage see
https://github.com/iriscouch/audit_couchdb/blob/master/cli.js#L13. you have
to pass the url in as a command line argument

max

On Tue, Aug 2, 2011 at 7:50 PM, Gregor Martynus <gregor@martynus.net> wrote:

> 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’t protect
> > against anyone accessing your raw CouchDB API. There’s at least one way
> > around it that should it be sufficient to illustrate why virtual hosts
> are
> > 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’t require a Host header at all. CouchDB’s default behaviour is
> > for each request that doesn’t match any virtual host for any reason, 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-urls
>
>
> 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
> _users?
> > 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
> dummies,
> > 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
> paid
> > > for any services on maxogden.com I would lock them down using couch's
> > > security model and tools like
> https://github.com/iriscouch/audit_couchdb
> > >
> > > 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
> again
> > > 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.html
> > > > >
> > > >
> > > > 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
> out
> > > > 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
> not
> > > > >> acceptable. Looking forward to a positive answer to your question,
> > > > >> Chang!
> > > > >>
> > > > >
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message