Closed clariontools closed 6 years ago
Woah! Never noticed that.
I have never really setup superlogin in a complete production environment to actually look into security concerns but in all of my simple demos that I used superlogin for, I changed the prefix of the users DB. So, I guess it would be hard for someone to guess that maybe? 😄
It looks like for CouchDB you can set a default Admin and Member _security document, but that seems to be only for the user dbs and not for sl-users, so I will need to look into this a bit more to see if there is a way to do this in the config https://github.com/colinskow/superlogin/blob/master/config.example.js .
No go on using the defaultSecurityRoles config option for sl-users the code is not there to support that. I think this is a pretty big security issue and FWIW, security is mentioned in the README.md, but it indicates that...
To block anonymous reads across all databases you can set require_valid_user to true under [couch_httpd_auth] in your CouchDB config.
Which is true for anonymous reads, but it does not handle authenticated _user tokens which are readily available to all logged in users and with that token you can have access to every bit of data in the sl-users db within a matter of seconds.
To harden the sl-users db here are some options:
I think 1. is the easiest thing to do, just have to remember to manually add the role anytime a new instance of superlogin is initialized or reinitialized. Would welcome any comments here while this is fresh before I close the issue.
Closed - Going with option 1. the manual route, just need to make it part of the setup checklist. Some mention of this could be helpful in the README.md, but it seems like for now this project is not actively merging PRs.
Similar to the situation talked about on issues #174 and #179, the sl-users db has no _security document when created so it can be accessed by any _users session user. I think it should maybe have a Members role of admin added when it is created in the _security doc. I tested it out manually by adding the admin role to Members -> Roles and it seems to solve the problem.
To see the problem in action, just grab a dbURL from a user session and replace the user private db like supertest$john with sl-users and you should be able to get access with curl or postman. You can do _all_docs or _all_docs?include_docs=true as the endpoint and see everything.
A bit surprised that this has not been patched by now, but maybe there is some other configuration that I missed?