CODEWITHSUNDEEP
securitycouchdb
Heptic
Heptic

Reputation: 3106

couchdb saftey of abitrary design docs

I am creating a couchdb database per user of my application, in which the application is granted database admin privileges. This is done so that the application can sync design docs -- but I do not want to expose my server to any risks.

There is no legitimate reason for a user to run a view on my server (they only use the server for 2-way sync'ing) so it wouldn't be hard to filter requests out that were attempting to view views?

Are there other security risks or DoS attacks I'm missing?

Upvotes: 0

Views: 49

Answers (1)

Kxepal
Kxepal

Reputation: 4679

Every user that has read access to your database is able to run view. That's not an issue since view index builds once and updates incrementally.

But database admins can create new views whatever they like. Views couldn't consume a lot of CPU time since CouchDB limits their execution with timeout (default 5 sec), but they could consume a lot of disk space, especially if full doc content will be emitted from view - this could make single index view be bigger than whole database.

More over, database admins can run database and view index compactions - these operations are very heavy for disk IO (and sometimes for CPU too), especially for large databases (100GiBs+). These tasks may significantly slow down (single compaction probably may not, but multiple - easily will) your server performance if will be running at the peak of your users activity.

Things can get worse if you're using custom view server without sandbox feature (like Python, Erlang etc.). By the fact, they will allow your db admins execute custom code on your server though CouchDB. In this case, losing all databases and finding remote shell on your server are just the top of the iceberg of possibilities.

Resume: don't assign to database admins people whom you cannot trust and you'll be safe.

Upvotes: 1

Related Questions