incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: Update Handlers as a safe entry point
Date Mon, 03 May 2010 08:47:10 GMT
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.
> 
> 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.
>> 
>> --
>> Paul Bonser
>> http://probablyprogramming.com
>> 
> 
> 
> 
> -- 
> Paul Bonser
> http://probablyprogramming.com

Mime
View raw message