Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1078)
Subject: Re: Update Handlers as a safe entry point
From: Jan Lehnardt <jan@apache.org>
In-Reply-To: <g2he6101e101005031347ic1074d95l8bcbf121c23ace71@mail.gmail.com>
Date: Mon, 3 May 2010 22:54:04 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <3A660B9F-7E64-40CD-9CC5-E967B2F0ADA1@apache.org>
References: <v2he6101e101004301113qa162fca3kf9abd2db3c5df7e3@mail.gmail.com>
  <v2ge6101e101005020906m383e3ecdnb1c98d729a9256e1@mail.gmail.com>
  <62398762-0604-441C-8436-ABC2C46E3D9A@apache.org>
 <E98BD181-D78A-4EE7-B0A0-27D167A72A43@gmail.com>
 <g2he6101e101005031347ic1074d95l8bcbf121c23ace71@mail.gmail.com>
To: dev@couchdb.apache.org


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

> On Mon, May 3, 2010 at 2:53 PM, J Chris Anderson <jchris@gmail.com> =
wrote:
>>=20
>> On May 3, 2010, at 1:47 AM, Jan Lehnardt wrote:
>>=20
>>> 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.
>>>=20
>>> I obviously haven't thought this through :)
>>>=20
>>> Cheers
>>> Jan
>>> --
>>>=20
>>>=20
>>> On 2 May 2010, at 18:06, Paul Bonser <misterpib@gmail.com> wrote:
>>>=20
>>>> Sorry for the wall of text there, but I had lots of thoughts to get =
out.
>>>>=20
>>>> 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.
>>=20
>> 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.
>>=20
>> I'll feel better about user password storage once we are using =
bcrypt.
>=20
> 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=20
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
--


>=20
>>=20
>> Chris
>>=20
>>>>=20
>>>> On Fri, Apr 30, 2010 at 1:13 PM, Paul Bonser <misterpib@gmail.com> =
wrote:
>>>>> Hey everyone,
>>>>>=20
>>>>> 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.
>>>>>=20
>>>>> Imagine this scenario:
>>>>>=20
>>>>> 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:
>>>>>=20
>>>>> - Start a new game
>>>>> - Make a move on an existing game
>>>>> - Forfeit a game
>>>>>=20
>>>>> 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.
>>>>>=20
>>>>> 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.
>>>>>=20
>>>>> 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).
>>>>>=20
>>>>> So my question now is: what is the best way to add the ability to
>>>>> check the source of a document update?
>>>>>=20
>>>>> 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.
>>>>>=20
>>>>> 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.
>>>>>=20
>>>>> 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.
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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.
>=20
> 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.
>=20
>>=20
>>>>>=20
>>>>> --
>>>>> Paul Bonser
>>>>> http://probablyprogramming.com
>>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> --
>>>> Paul Bonser
>>>> http://probablyprogramming.com
>>=20
>>=20
>=20
>=20
>=20
> --=20
> Paul Bonser
> http://probablyprogramming.com