couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <>
Subject Re: Update Handlers as a safe entry point
Date Mon, 03 May 2010 20:54:04 GMT

On 3 May 2010, at 22:47, Paul Bonser wrote:

> On Mon, May 3, 2010 at 2:53 PM, J Chris Anderson <> wrote:
>> 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 <> 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.
> With a vhost and rewrite it would still be vulnerable to someone who
> leaves out a Host header, wouldn't it?

Agreed. vhosts & rewrite are not security devices.

> Is there a reason not to add read validation functions which work
> along the same lines as write validation functions? Aside from the
> fact that it would complicate the view fetching code? Perhaps for
> views the reader list is used, but for individual document requests
> the read validation function is used?

List functions are to views what show functions are to documents. If 
you need to "disguise" view results, that should happen in a "blessed"
list function, too.

Please keep poking holes into the (vague) proposal, it might turn out
to be a bad idea :)


>> Chris
>>>> On Fri, Apr 30, 2010 at 1:13 PM, Paul Bonser <>
>>>>> 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.
> I do want to be able to replicate, so that makes sense. Part of the
> idea is the ability for a user to replicate their games down to a
> local machine, make moves while disconnected, and then replicate the
> games back up to the server. Since I'll have to validate that the
> documents they are trying to replicate to the server are valid moves,
> so I'll have to do all the validation either way.
>>>>> --
>>>>> Paul Bonser
>>>> --
>>>> Paul Bonser
> -- 
> Paul Bonser

View raw message