incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Bonser <mister...@gmail.com>
Subject Re: Update Handlers as a safe entry point
Date Sun, 02 May 2010 16:06:40 GMT
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