couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From J Chris Anderson <jch...@gmail.com>
Subject rewrite security
Date Wed, 05 May 2010 22:35:50 GMT
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



Mime
View raw message