You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Paweł Stawicki <pa...@gmail.com> on 2010/01/03 14:31:19 UTC
Common security pattern?
Hello,
I am thinking about using CouchDB in app I want to create. In CouchDB
I can get documents directly from client's browser by javaScript and
it is great, but I have some concerns. I want the app to be accessible
to everyone without need to have an account or log in (like
wikipedia). If I want everyone to have access to documents, CouchDB
has to be accessible to the whole internet. If this is the case,
everyone can even delete whole database by single HTTP query :(
It is unevitable that if DB is accessible in the internet, everyone
can edit/add/delete documents. After all, this is what I want. But I
don't want to allow deletion of whole database. Or access to another
databases on the same CouchDB server.
Even if I can prevent deletion of whole database, I can't prevent
deletion of single documents, and malicious user could delete them one
by one.
So in a nutshell, I have questions:
1. Is it possible to prevent deletion of database?
2. Is it possible to prevent deletion of documents? Or, even better...
3. ...is it possible to limit number of deleted documents for specific
IP for time unit. E.g. one document deletion per minute?
Best regards
--
Paweł Stawicki
http://pawelstawicki.blogspot.com
http://szczecin.jug.pl
http://www.java4people.com
Re: Common security pattern?
Posted by Paweł Stawicki <pa...@gmail.com>.
On Sun, Jan 3, 2010 at 17:52, Sean Hess <se...@gmail.com> wrote:
> I'm brand new at this, so I don't know the common way to solve this,
> but I was thinking it should be possible to put it behind nginx or
> apache, and simply return a 503 code if they tried to hit your
> database url instead of a document.
Yes, that's some solution, but what with deleting documents?
> If that doesn't work, you could always put a thin middleware layer in
> front of couch that did nothing but security. (You can get webservers
> to give you the intended URL as a variable)
And yes, this seems to be good solution. This way I can let user
delete, but limit the deletes. This is what I want.
But anyway, I am interested how this issue is usually solved, what is
common pattern.
Thanks!
--
Paweł Stawicki
http://pawelstawicki.blogspot.com
http://szczecin.jug.pl
http://www.java4people.com
Re: Common security pattern?
Posted by Chris Anderson <jc...@apache.org>.
On Sun, Jan 3, 2010 at 3:21 PM, Sam Bisbee <sb...@computervip.com> wrote:
> On Sun, Jan 03, 2010 at 01:18:26PM -0800, Chris Anderson wrote:
>> On Sun, Jan 3, 2010 at 1:10 PM, Nathan Stott <nr...@gmail.com> wrote:
>> > If a user can access a document via Futon, he can access via the CouchDB API
>> > if he knows what he's doing. The data is exposed one way or the other if
>> > you store it in documents that users can access. There is no key-level
>> > protection on a document that I am aware of. Correct me if I'm wrong,
>> > someone.
>> >
>>
>> There is key-level write protection. There is not key-level read
>> protection, and there are no plans to add it.
>>
>> Per document read-control turns out to be extremely non-trivial (think
>> about information leakage via reduce, etc) such that Lotus Notes never
>> even got it right.
>
> Out of interest, is there some documentation available on the subject (maybe a
> CouchDB or Lotus Notes dev's blog post)? Also, I assume that this leakage would
> only happen locally and isn't exposed to remote users?
>
There might be some discussion in the ML archives.
The leakage is to anyone accessing the views.
Basically, if you have a doc, with a list of users who are allowed to
read it, it's not very hard to enforce. If that doc is in a map view,
you can also mark the view rows with the list of allowed readers, and
filter at query time to only show valid rows. Also not that hard.
However, if you have a reduce function (calculating, say, total
account balance) the results can leak private data to other users. The
best solution would be to run the reduce on the client (against the
filtered map rows) but then you lose all the benefits of reduce.
It's not that it's absolutely impossible to do this, it's just that
it's hard to think of a way that doesn't cause lots of unanticipated
security headaches for devs.
There's an alternate line of thought: if the server enforces read
access per documents, and doesn't offer views at all, then users can
replicate their slice of the database locally and run views on their
local CouchDB. I think this isn't much different (in terms of the use
cases it can support) from encouraging a database-per-user model,
where users have read access to their entire database. Db-per-user is
much simpler, and we plan to support it.
Chris
> Thanks,
>
> --
> Sam Bisbee
>
--
Chris Anderson
http://jchrisa.net
http://couch.io
Re: Common security pattern?
Posted by Sam Bisbee <sb...@computervip.com>.
On Sun, Jan 03, 2010 at 01:18:26PM -0800, Chris Anderson wrote:
> On Sun, Jan 3, 2010 at 1:10 PM, Nathan Stott <nr...@gmail.com> wrote:
> > If a user can access a document via Futon, he can access via the CouchDB API
> > if he knows what he's doing. The data is exposed one way or the other if
> > you store it in documents that users can access. There is no key-level
> > protection on a document that I am aware of. Correct me if I'm wrong,
> > someone.
> >
>
> There is key-level write protection. There is not key-level read
> protection, and there are no plans to add it.
>
> Per document read-control turns out to be extremely non-trivial (think
> about information leakage via reduce, etc) such that Lotus Notes never
> even got it right.
Out of interest, is there some documentation available on the subject (maybe a
CouchDB or Lotus Notes dev's blog post)? Also, I assume that this leakage would
only happen locally and isn't exposed to remote users?
Thanks,
--
Sam Bisbee
Re: Common security pattern?
Posted by Chris Anderson <jc...@apache.org>.
On Sun, Jan 3, 2010 at 1:10 PM, Nathan Stott <nr...@gmail.com> wrote:
> If a user can access a document via Futon, he can access via the CouchDB API
> if he knows what he's doing. The data is exposed one way or the other if
> you store it in documents that users can access. There is no key-level
> protection on a document that I am aware of. Correct me if I'm wrong,
> someone.
>
There is key-level write protection. There is not key-level read
protection, and there are no plans to add it.
Per document read-control turns out to be extremely non-trivial (think
about information leakage via reduce, etc) such that Lotus Notes never
even got it right.
Chris
> On Sun, Jan 3, 2010 at 2:07 PM, Sam Bisbee <sb...@computervip.com> wrote:
>
>> On Sun, Jan 03, 2010 at 11:40:32AM -0800, Chris Anderson wrote:
>> > I'd avoid thinking that hiding Futon provides security. Ideally users
>> > would be able to get into the data via Futon if they choose. If you
>> > structure your validation functions properly, this should be
>> > completely secure (more secure than an http-proxy based authorization
>> > model).
>>
>> This strikes me as an odd and interesting proposition (read: the good
>> kind).
>>
>> I can think of plenty of cases where I don't want users to see all the data
>> that I have related to them: ex., hashed/crypted passwords, analytics,
>> various
>> types of scores/weights, my profit margin on their purchases, etc. Allowing
>> users to inspect documents about themselves through Futon would allow them
>> to
>> see all those goodies.
>>
>> Also, I have always been of the mind that even if something doesn't
>> inherently
>> cause a security flaw, that you shouldn't give it to your users if you
>> don't
>> need to (users are too good at breaking things in ways that you don't
>> expect,
>> especially the malicious ones).
>>
>> Not that I'm not a fan of open APIs (actually, I'm a huge fan), but even
>> those
>> enforce validation/rules.
>>
>> Or were you discussing a specific use case?
>>
>> Cheers,
>>
>> --
>> Sam Bisbee
>>
>
--
Chris Anderson
http://jchrisa.net
http://couch.io
Re: Common security pattern?
Posted by Nathan Stott <nr...@gmail.com>.
If a user can access a document via Futon, he can access via the CouchDB API
if he knows what he's doing. The data is exposed one way or the other if
you store it in documents that users can access. There is no key-level
protection on a document that I am aware of. Correct me if I'm wrong,
someone.
On Sun, Jan 3, 2010 at 2:07 PM, Sam Bisbee <sb...@computervip.com> wrote:
> On Sun, Jan 03, 2010 at 11:40:32AM -0800, Chris Anderson wrote:
> > I'd avoid thinking that hiding Futon provides security. Ideally users
> > would be able to get into the data via Futon if they choose. If you
> > structure your validation functions properly, this should be
> > completely secure (more secure than an http-proxy based authorization
> > model).
>
> This strikes me as an odd and interesting proposition (read: the good
> kind).
>
> I can think of plenty of cases where I don't want users to see all the data
> that I have related to them: ex., hashed/crypted passwords, analytics,
> various
> types of scores/weights, my profit margin on their purchases, etc. Allowing
> users to inspect documents about themselves through Futon would allow them
> to
> see all those goodies.
>
> Also, I have always been of the mind that even if something doesn't
> inherently
> cause a security flaw, that you shouldn't give it to your users if you
> don't
> need to (users are too good at breaking things in ways that you don't
> expect,
> especially the malicious ones).
>
> Not that I'm not a fan of open APIs (actually, I'm a huge fan), but even
> those
> enforce validation/rules.
>
> Or were you discussing a specific use case?
>
> Cheers,
>
> --
> Sam Bisbee
>
Re: Common security pattern?
Posted by Chris Anderson <jc...@apache.org>.
On Sun, Jan 3, 2010 at 12:07 PM, Sam Bisbee <sb...@computervip.com> wrote:
> On Sun, Jan 03, 2010 at 11:40:32AM -0800, Chris Anderson wrote:
>> I'd avoid thinking that hiding Futon provides security. Ideally users
>> would be able to get into the data via Futon if they choose. If you
>> structure your validation functions properly, this should be
>> completely secure (more secure than an http-proxy based authorization
>> model).
>
> This strikes me as an odd and interesting proposition (read: the good kind).
>
> I can think of plenty of cases where I don't want users to see all the data
> that I have related to them: ex., hashed/crypted passwords, analytics, various
> types of scores/weights, my profit margin on their purchases, etc. Allowing
> users to inspect documents about themselves through Futon would allow them to
> see all those goodies.
>
> Also, I have always been of the mind that even if something doesn't inherently
> cause a security flaw, that you shouldn't give it to your users if you don't
> need to (users are too good at breaking things in ways that you don't expect,
> especially the malicious ones).
>
> Not that I'm not a fan of open APIs (actually, I'm a huge fan), but even those
> enforce validation/rules.
>
> Or were you discussing a specific use case?
>
The use case I'm thinking of is any that involves CouchDB on the net.
If you have data you don't want read, it should go into a
read-restricted database (please do implement...). Otherwise,
validation functions are the 100% best way to prevent unwanted
updates.
The worry is that someone will think they've added security by
disallowing access to /_utils. As long as you allow users's browsers
to access CouchDB via HTTP, you should cross the t's and dot the i's
of validation functions, so that you are confident enough to allow
Futon access. Anything less is security by obscurity.
Chris
--
Chris Anderson
http://jchrisa.net
http://couch.io
Re: Common security pattern?
Posted by Sam Bisbee <sb...@computervip.com>.
On Sun, Jan 03, 2010 at 11:40:32AM -0800, Chris Anderson wrote:
> I'd avoid thinking that hiding Futon provides security. Ideally users
> would be able to get into the data via Futon if they choose. If you
> structure your validation functions properly, this should be
> completely secure (more secure than an http-proxy based authorization
> model).
This strikes me as an odd and interesting proposition (read: the good kind).
I can think of plenty of cases where I don't want users to see all the data
that I have related to them: ex., hashed/crypted passwords, analytics, various
types of scores/weights, my profit margin on their purchases, etc. Allowing
users to inspect documents about themselves through Futon would allow them to
see all those goodies.
Also, I have always been of the mind that even if something doesn't inherently
cause a security flaw, that you shouldn't give it to your users if you don't
need to (users are too good at breaking things in ways that you don't expect,
especially the malicious ones).
Not that I'm not a fan of open APIs (actually, I'm a huge fan), but even those
enforce validation/rules.
Or were you discussing a specific use case?
Cheers,
--
Sam Bisbee
Re: Common security pattern?
Posted by Chris Anderson <jc...@apache.org>.
On Sun, Jan 3, 2010 at 11:21 AM, Karel Minařík <ka...@gmail.com> wrote:
> Hi,
>
>> Everything except the throttling of deletes for a given user should be
>> easy to do natively with CouchDB.
>
> how about anyone accessing other databases, documents? Ie., I want to expose
> one database, containing the app (blog, wiki, etc), but not allow anyone
> browse databases, use Futon, etc. As far as I know the only way how to
> accomplish that would be to put reverse-proxy between the public and couch.
I'd avoid thinking that hiding Futon provides security. Ideally users
would be able to get into the data via Futon if they choose. If you
structure your validation functions properly, this should be
completely secure (more secure than an http-proxy based authorization
model).
OTOH, if you want to make some databases private (read-control),
CouchDB does not have a provision for that. Using an HTTP proxy layer
is great for this usage. And if you do it right, it has the advantage
that Futon should work fine for databases the user has permission to
read.
We are planning per-database reader ACLs, hopefully in time for 0.11,
depending on how complex the patch is.
Chris
>
> Karel
>
--
Chris Anderson
http://jchrisa.net
http://couch.io
Re: Common security pattern?
Posted by Karel Minařík <ka...@gmail.com>.
Hi,
> Everything except the throttling of deletes for a given user should be
> easy to do natively with CouchDB.
how about anyone accessing other databases, documents? Ie., I want to
expose one database, containing the app (blog, wiki, etc), but not
allow anyone browse databases, use Futon, etc. As far as I know the
only way how to accomplish that would be to put reverse-proxy between
the public and couch.
Karel
Re: Common security pattern?
Posted by Chris Anderson <jc...@apache.org>.
On Sun, Jan 3, 2010 at 10:13 AM, Karel Minařík <ka...@gmail.com> wrote:
> Hi,
>
>> On Jan 3, 2010, at 6:31 AM, Paweł Stawicki <pa...@gmail.com>
>>>
>>> It is unevitable that if DB is accessible in the internet, everyone
>>> can edit/add/delete documents. After all, this is what I want. But I
>>> don't want to allow deletion of whole database. Or access to another
>>> databases on the same CouchDB server.
>
>>> Even if I can prevent deletion of whole database, I can't prevent
>>> deletion of single documents, and malicious user could delete them one
>>> by one.
>
>>> So in a nutshell, I have questions:
>>> 1. Is it possible to prevent deletion of database?
>>> 2. Is it possible to prevent deletion of documents? Or, even better...
>>> 3. ...is it possible to limit number of deleted documents for specific
>>> IP for time unit. E.g. one document deletion per minute?
>
> I am quite green in this area, but I've been thinking a bit about this
> lately and IMHO you can do several things:
>
> First, you can hook up your application with some reverse-proxy, as Sean
> Hess adviced. This way you can expose only the URL to one database (and
> possibly to the _design/myapp document, so you get nicer URLs). In Nginx,
> you'd do something like this: http://gist.github.com/268061, it would be
> very similar in Apache. This way, you're not exposing the whole couch, but
> only that specific database, restricting the access.
>
> Then, you can implement basic authentication
> [http://books.couchdb.org/relax/reference/security], which basically will
> disallow anyone to create/delete design docs and other stuff (see the relax
> book for listing.) Anyone un-authorized can still create/update/delete
> "regular" documents, which is what you want.
>
> Then again, you can restrict deleting/updating/etc docs to the user who
> originally created those (which is basically what @jchrisa's sofa does, see
> http://github.com/jchris/sofa/blob/master/validate_doc_update.js#L12-14), or
> disallow deleting docs entirely (again see @jchrisa's toast,
> http://github.com/jchris/toast/blob/master/validate_doc_update.js#L10-14).
> (In a Wiki, it could make sense to disallow deleting docs, unless
> authorized, etc)
>
> I am not sure how to limit number of deletions per IP+time, unless you have
> some authentication info about the user...
>
Everything except the throttling of deletes for a given user should be
easy to do natively with CouchDB.
Only admins can create and destroy DBs, install design docs, etc.
If you want to see a preview of the new login feature, it's available
at http://github.com/jchris/couchdb/tree/account
See the bottom right hand corner of Futon. Comments/patches very welcome!
I plan to merge it to trunk before 0.11 release, so it should be a
viable option for new apps.
Chris
--
Chris Anderson
http://jchrisa.net
http://couch.io
Re: Common security pattern?
Posted by Karel Minařík <ka...@gmail.com>.
Hi,
> On Jan 3, 2010, at 6:31 AM, Paweł Stawicki <pa...@gmail.com>
>> It is unevitable that if DB is accessible in the internet, everyone
>> can edit/add/delete documents. After all, this is what I want. But I
>> don't want to allow deletion of whole database. Or access to another
>> databases on the same CouchDB server.
>> Even if I can prevent deletion of whole database, I can't prevent
>> deletion of single documents, and malicious user could delete them
>> one
>> by one.
>> So in a nutshell, I have questions:
>> 1. Is it possible to prevent deletion of database?
>> 2. Is it possible to prevent deletion of documents? Or, even
>> better...
>> 3. ...is it possible to limit number of deleted documents for
>> specific
>> IP for time unit. E.g. one document deletion per minute?
I am quite green in this area, but I've been thinking a bit about this
lately and IMHO you can do several things:
First, you can hook up your application with some reverse-proxy, as
Sean Hess adviced. This way you can expose only the URL to one
database (and possibly to the _design/myapp document, so you get nicer
URLs). In Nginx, you'd do something like this: http://gist.github.com/268061
, it would be very similar in Apache. This way, you're not exposing
the whole couch, but only that specific database, restricting the
access.
Then, you can implement basic authentication [http://books.couchdb.org/relax/reference/security
], which basically will disallow anyone to create/delete design docs
and other stuff (see the relax book for listing.) Anyone un-
authorized can still create/update/delete "regular" documents, which
is what you want.
Then again, you can restrict deleting/updating/etc docs to the user
who originally created those (which is basically what @jchrisa's sofa
does, see http://github.com/jchris/sofa/blob/master/validate_doc_update.js#L12-14)
, or disallow deleting docs entirely (again see @jchrisa's toast, http://github.com/jchris/toast/blob/master/validate_doc_update.js#L10-14)
. (In a Wiki, it could make sense to disallow deleting docs, unless
authorized, etc)
I am not sure how to limit number of deletions per IP+time, unless you
have some authentication info about the user...
Karel
Re: Common security pattern?
Posted by Sean Hess <se...@gmail.com>.
I'm brand new at this, so I don't know the common way to solve this,
but I was thinking it should be possible to put it behind nginx or
apache, and simply return a 503 code if they tried to hit your
database url instead of a document.
If that doesn't work, you could always put a thin middleware layer in
front of couch that did nothing but security. (You can get webservers
to give you the intended URL as a variable)
On Jan 3, 2010, at 6:31 AM, Paweł Stawicki <pa...@gmail.com>
wrote:
> Hello,
>
> I am thinking about using CouchDB in app I want to create. In CouchDB
> I can get documents directly from client's browser by javaScript and
> it is great, but I have some concerns. I want the app to be accessible
> to everyone without need to have an account or log in (like
> wikipedia). If I want everyone to have access to documents, CouchDB
> has to be accessible to the whole internet. If this is the case,
> everyone can even delete whole database by single HTTP query :(
>
> It is unevitable that if DB is accessible in the internet, everyone
> can edit/add/delete documents. After all, this is what I want. But I
> don't want to allow deletion of whole database. Or access to another
> databases on the same CouchDB server.
>
> Even if I can prevent deletion of whole database, I can't prevent
> deletion of single documents, and malicious user could delete them one
> by one.
>
> So in a nutshell, I have questions:
> 1. Is it possible to prevent deletion of database?
> 2. Is it possible to prevent deletion of documents? Or, even better...
> 3. ...is it possible to limit number of deleted documents for specific
> IP for time unit. E.g. one document deletion per minute?
>
> Best regards
> --
> Paweł Stawicki
> http://pawelstawicki.blogspot.com
> http://szczecin.jug.pl
> http://www.java4people.com