On 3 May 2010, at 22:47, Paul Bonser wrote: > On Mon, May 3, 2010 at 2:53 PM, J Chris Anderson <[email protected]> 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 <[email protected]> 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 :) Cheers Jan -- > >> >> Chris >> >>>> >>>> On Fri, Apr 30, 2010 at 1:13 PM, Paul Bonser <[email protected]> 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. > > 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 >>>>> http://probablyprogramming.com >>>>> >>>> >>>> >>>> >>>> -- >>>> Paul Bonser >>>> http://probablyprogramming.com >> >> > > > > -- > Paul Bonser > http://probablyprogramming.com
