On 2/11/2009 9:13 AM, Paul Davis wrote:
couchjs security
...
The first step to securing cURL handlers I'm going to tackle is the
basic all-or-nothing HTTP support. With something like --with-http as
Chris suggests. Mark also made a suggestion on including a
--with-http-host=127.0.0.1 or similar to support HTTP requests to a
specific host only. This is probably doable but I'll have to think a
bit harder on how to force that in the cURL handlers.
My use-case is to avoid allowing full-blown cURL access to javascript
while still allowing a couchdb 'external' to have access to "its"
database. Specifically, I want to use the 'externals' mechanism to
build an application specific API - an API which hides/abstracts
multiple couchdb calls and subsequent data munging into a single call
which is more relevant to the application's direct requirements.
For example, if I have an external which is referenced via
http://host:port/dbname/_external, the implementation of that external
needs access to the referenced 'dbname', but no others.
On IRC, there were 2 thoughts:
* Paul mentioned the cmd-line switch to disable cURL - if we provided a
new option that only allowed connections back to the same DB (probably
by exposing an API where the host and DB name can't even be specified by
the js code), it might still meet the general security requirements.
* Benoit mentioned that if we changed the externals 'protocol' slightly,
we could probably offer a javascript API back to the database which uses
stdin/stdout to exchange requests and responses, allowing us to live
without cURL support at all. Such an API may also be able to help allow
cron jobs etc to have "safe side-effects" - the only side-effects they
can perform are ones exposed by couchdb itself, not via generic http
requests.
The second option sounds better, but much more work. I'm willing to
roll my sleeves up on this, so please share your thoughts (or ask me to
expand on my use-case if necessary)
Thanks,
Mark
