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 <m...@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.le...@gmail.com
> >wrote:
>
> > On Mon, Aug 1, 2011 at 14:33, Sam Kearns <s...@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<ch...@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!
> > >>
> > >
> >
>
