rewrite security

[J Chris Anderson <jc...@gmail.com>]

Devs,

Today I wrote a patch and backported to 0.11.x, concerning the security guarantees made by the rewriter.

Previously we'd allowed the rewriter to include as many ".." segments in the target path as the developer wanted. This is great for flexibility, and allows you to create a vhost which doesn't provide the full couchdb api but also can access more than one database.

I've changed the default behavior so that you can only have a maximum of 2 ".." segments in your rewrite paths, so eg you can rewrite from /db/_design/foo/_rewrite to /db/ or /db/somedoc or /db/_design/foo/_show/bar but you CAN'T rewrite to /otherdb/anything

This allows databases to be "jailed" inside vhosts, which is very important for security as we move forward. Prior to this patch, there was no way to run untrusted apps on the same CouchDB VM as each other. Now, using vhosts and by putting apps/dbs on different domains, we can protect the applications from each other.

My patch maintains the previous functionality (unlimited rewriting), but it is configured to be off by default. By default secure_rewrites=true. So if you are currently relying on cross-db rewrites, you'll need to edit your local.ini file to set secure_rewrites=false 

There are some missing parts in my implementation. I plan to finish this change by making a configurable whitelist of global_httpd handlers that *can* be accessed within vhosts. The ones I can think of are:

_utils
_uuids
_session
_oauth
_users

And some installations might want to turn on others (_replicate, _stats, etc), hence the list should be configurable.

My plan is to implement this as a whitelist that is checked by the vhost engine, so that these global handlers are available on all vhosts. This way you can easily add a database that needs to be available to all your vhosts using a single configuration directive.

I think this plan is sane, but please let me know if you see issues that I'm missing.

Chris

Re: rewrite security

[Benoit Chesneau <bc...@gmail.com>]

On Thu, May 6, 2010 at 12:35 AM, J Chris Anderson <jc...@gmail.com> wrote:
> Devs,
>
> Today I wrote a patch and backported to 0.11.x, concerning the security guarantees made by the rewriter.
>
> Previously we'd allowed the rewriter to include as many ".." segments in the target path as the developer wanted. This is great for flexibility, and allows you to create a vhost which doesn't provide the full couchdb api but also can access more than one database.
>
> I've changed the default behavior so that you can only have a maximum of 2 ".." segments in your rewrite paths, so eg you can rewrite from /db/_design/foo/_rewrite to /db/ or /db/somedoc or /db/_design/foo/_show/bar but you CAN'T rewrite to /otherdb/anything
>
> This allows databases to be "jailed" inside vhosts, which is very important for security as we move forward. Prior to this patch, there was no way to run untrusted apps on the same CouchDB VM as each other. Now, using vhosts and by putting apps/dbs on different domains, we can protect the applications from each other.
>
> My patch maintains the previous functionality (unlimited rewriting), but it is configured to be off by default. By default secure_rewrites=true. So if you are currently relying on cross-db rewrites, you'll need to edit your local.ini file to set secure_rewrites=false
>
> There are some missing parts in my implementation. I plan to finish this change by making a configurable whitelist of global_httpd handlers that *can* be accessed within vhosts. The ones I can think of are:
>
> _utils
> _uuids
> _session
> _oauth
> _users
>
> And some installations might want to turn on others (_replicate, _stats, etc), hence the list should be configurable.
>
> My plan is to implement this as a whitelist that is checked by the vhost engine, so that these global handlers are available on all vhosts. This way you can easily add a database that needs to be available to all your vhosts using a single configuration directive.
>
> I think this plan is sane, but please let me know if you see issues that I'm missing.
>
> Chris
>
>
>


Well vhost don't stop someone to access to the whole db currently if
so remove the Host info or such.

But I'm not sure this path worth it since we can limit security per
database for readers & such. In fact, I would do in the other way, ie
secure the resource that need to be secured: _replicate, _all_dbs,
_users, ... . And maybe secure by default all resource to admin or a
default group of user. Using this way would allow other users of
couchdb (those who aren't using couchapps) to have a way to secure
these accesses to between untrusted users.

In your case, for hosting multiple non trusted couchapps, you would
just have to set default permissions to a couchdb node and it would do
the trick too.

What do you think about it ?

- benoit