I am building some Web-based services for a project I'm involved with, using the BaseX REST interface, and the experience has given me an idea for a possible enhancement to BaseX.
It's extremely convenient for development to be able to issue arbitrary queries from the REST interface, but in my role as part-time system administrator and worrier about security, the REST 'query', 'command', and 'get' operations worry me to death. I am happy for the user access control provided by the GRANT command, and I find myself thinking it would be even nicer to have more control.
I am happy to discover by experiment that a user with READ access only to a single database sees only that database name when they issue the the default GET request (http://hostname:8984/rest).
When I allow my security paranoia full sway, I find I would like to be able to ensure that only authorized users can
- perform arbitrary queries using the 'query' or 'command' interfaces - perform particular queries using the 'run' interface
Concretely, in this case I would like to be able to create a user for restricted access, which I'll call PUBLIC for now, and ensure that a user who presents the PUBLIC userid and password
- cannot fetch any data using the GET interface - cannot run queries using the rest:query interface - cannot run commands using the rest:command interface - can run only specified modules from the HTTPPATH directory (so we can limit the portions of the database we expose to the PUBLIC user -- I think of this as very roughly analogous to being able to limit a SQL user to particular views instead of to the underlying base tables)
Of course, by running a packet filter we can ensure that the BaseX server only receives packets from (or: purporting to be from) the project's host, and we can keep the user password for the PUBLIC user secret in what I believe is the usual way (it's there in the source of the PHP module, but web users don't get to see the source of the module). The restrictions I have in mind would serve the purpose of attempting to limit the damage an adversarial user could cause if the user credentials were exposed or (in the case of limiting users to specific modules) if an adversary were able to add modules to the HTTPPATH directory.
Disclaimer: I am not a security expert, just (at the moment) a worrier. You will surely be able to get advice from people who understand security issues better than I do.
Thank you again for this extremely helpful software.
…just some short feedback for today: the major challenge we are probably confronted when it comes to our user management is to find a minimum and consistent subset of functionality that covers as many use cases as possible. This said, your suggestions are helpful, and will turn out to be even more useful as soon as we manage to have another look at our current solution.
Talking about public users, you’d like to restrict their access to the RUN operation and certain HTTPPATH directories, right? In our own applications, we usually work with RESTXQ, as it allows more fine granular access to XQuery scripts. A while ago, there has been some initial discussion on best practices around web app authentication [1]. If we manage to get an ongoing discussion here, it would be great if we ended up with a solution that provides both REST and RESTXQ with additional security features.
All the best, Christian
[1] http://www.mail-archive.com/basex-talk@mailman.uni-konstanz.de/msg01679.html ___________________________
On Sat, Dec 22, 2012 at 2:33 AM, C. M. Sperberg-McQueen cmsmcq@blackmesatech.com wrote:
I am building some Web-based services for a project I'm involved with, using the BaseX REST interface, and the experience has given me an idea for a possible enhancement to BaseX.
It's extremely convenient for development to be able to issue arbitrary queries from the REST interface, but in my role as part-time system administrator and worrier about security, the REST 'query', 'command', and 'get' operations worry me to death. I am happy for the user access control provided by the GRANT command, and I find myself thinking it would be even nicer to have more control.
I am happy to discover by experiment that a user with READ access only to a single database sees only that database name when they issue the the default GET request (http://hostname:8984/rest).
When I allow my security paranoia full sway, I find I would like to be able to ensure that only authorized users can
- perform arbitrary queries using the 'query' or 'command' interfaces
- perform particular queries using the 'run' interface
Concretely, in this case I would like to be able to create a user for restricted access, which I'll call PUBLIC for now, and ensure that a user who presents the PUBLIC userid and password
- cannot fetch any data using the GET interface
- cannot run queries using the rest:query interface
- cannot run commands using the rest:command interface
- can run only specified modules from the HTTPPATH directory (so we can limit the portions of the database we expose to the PUBLIC user -- I think of this as very roughly analogous to being able to limit a SQL user to particular views instead of to the underlying base tables)
Of course, by running a packet filter we can ensure that the BaseX server only receives packets from (or: purporting to be from) the project's host, and we can keep the user password for the PUBLIC user secret in what I believe is the usual way (it's there in the source of the PHP module, but web users don't get to see the source of the module). The restrictions I have in mind would serve the purpose of attempting to limit the damage an adversarial user could cause if the user credentials were exposed or (in the case of limiting users to specific modules) if an adversary were able to add modules to the HTTPPATH directory.
Disclaimer: I am not a security expert, just (at the moment) a worrier. You will surely be able to get advice from people who understand security issues better than I do.
Thank you again for this extremely helpful software.
--
- C. M. Sperberg-McQueen, Black Mesa Technologies LLC
- http://www.blackmesatech.com
- http://cmsmcq.com/mib
- http://balisage.net
BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
basex-talk@mailman.uni-konstanz.de
-
C. M. Sperberg-McQueen -
Christian Grün