incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From J Chris Anderson <jch...@gmail.com>
Subject Re: Update Handlers as a safe entry point
Date Mon, 03 May 2010 19:53:21 GMT

On May 3, 2010, at 1:47 AM, Jan Lehnardt wrote:

> May back-of-the-head solution for this scenario is to introduce "blessing" of update
functions so they are invoked on regular API calls. Same for show functions.
> 
> I obviously haven't thought this through :)
> 
> Cheers
> Jan
> --
> 
> 
> On 2 May 2010, at 18:06, Paul Bonser <misterpib@gmail.com> wrote:
> 
>> Sorry for the wall of text there, but I had lots of thoughts to get out.
>> 
>> Another good use of the ability to allow update handlers but reject
>> direct POSTing of documents, would be to allow users to register new
>> accounts, but not allow them general access to the _users DB. As it
>> stands right now it's a huge security hole that anybody can read from
>> the _users db, including the salt and hashed password of any user.

There is definitely something to this. Since the users db isn't replicated you don't really
need access to it (except to your own user doc) and to create new ones. I think this can be
done with vhost and rewrite too. 

I'll feel better about user password storage once we are using bcrypt.

Chris

>> 
>> On Fri, Apr 30, 2010 at 1:13 PM, Paul Bonser <misterpib@gmail.com> wrote:
>>> Hey everyone,
>>> 
>>> I've been looking at update handlers, and I see a real opportunity to
>>> simplify application development and more easily secure an application
>>> which allows users to communicate directly with CouchDB.
>>> 
>>> Imagine this scenario:
>>> 
>>> I'm building a couchapp which allows users to play board games against
>>> one another. There are only a fairly small number of things involving
>>> a change to the DB that a player can do:
>>> 
>>> - Start a new game
>>> - Make a move on an existing game
>>> - Forfeit a game
>>> 
>>> So, instead of teaching the client code all about the format of the
>>> document, and then in a validate_doc_update function checking every
>>> field to make sure the user didn't do anything they shouldn't have, I
>>> simply make an update handler for each of these possibilities, and the
>>> user only gives the minimum required input "This is the game I'm
>>> referring to, move my piece from a5 to c7." The update handler just
>>> has to check if that's a valid move, and it knows that none of the
>>> fields have been modified.
>>> 
>>> The problem is, if a user can make a call to an update handler, they
>>> can also POST directly to a document, so I still need to have a
>>> validate_doc_update function, and since they could potentially still
>>> POST directly, I *still* have to check every field to make sure they
>>> didn't do anything they shouldn't have.
>>> 
>>> Basically, what I need is some way of being able to check, within a
>>> validate_doc_update function, what means the user used to update the
>>> document, and then all I'd have to do is check if the update came via
>>> a update handler, and I'll know the changes are safe (assuming I wrote
>>> my update handler safely).
>>> 
>>> So my question now is: what is the best way to add the ability to
>>> check the source of a document update?
>>> 
>>> My first thought would be to insert an attribute into the (as yet
>>> undocumented) fourth argument to validate_doc_update functions,
>>> indicating where the request came from. That could either be the path
>>> of the request, or perhaps a string indicating what request type it
>>> was. The only problem with this approach is that it doesn't carry over
>>> into replication very well.
>>> 
>>> My second idea would be to allow update handlers to indicate in their
>>> response that the document update should happen under the identity of
>>> a different user. That way, an update handler just sets the updating
>>> user to be some user that has admin access to the current database,
>>> and the validate_doc_update function just has to check that the
>>> updating user has the admin role.
>>> 
>>> Any thoughts or comments? If either of those ideas sounds reasonable,
>>> I'd gladly offer to write the patch to add the new functionality
>>> myself.

I think this is dangerous. As soon as you use more than the validation function for write
security you sacrifice the ability to replicate your applications.

You can do something similar with vhosts and _rewrite. I think it is generally better to use
a vhost for this problem than trying to overload the CouchDB APIs.

It is always best to make sure your validation functions are sufficient for update control.
Then you can think of read-protection as a distinct problem, instead of mixing up access control
with validation. I think it makes for more secure apps.

>>> 
>>> --
>>> Paul Bonser
>>> http://probablyprogramming.com
>>> 
>> 
>> 
>> 
>> -- 
>> Paul Bonser
>> http://probablyprogramming.com


Mime
View raw message