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.