Logging out of an existing user removes security roles from this users database making it public

[jockjocko]

Steps

• Create a user using "auth/register"
• Check permissions of that users database and you will see that it is secure
• Logout using "auth/logout"
• Check permissions of that users database and you will see that it is no longer secure

[saip92]

True.

I think the easiest fix would be to add a role 'user:' to each of the private databases on register.

[peteruithoven]

It's been a while since I looked into this, but does this apply to both CouchDB and Cloudant? On Cloudant, for example, there is a separate Unauthenticated connections / nobody field, so I'm hoping it doesn't apply to Cloudant.

[OnnoGabriel]

A database is only available to public in CouchDB as long as the admin party is not de-activated, isn't it?

It is not in a fresh installation, though. To secure CouchDB, some steps have to be done, like setting up an admin.

See CouchDB Guide.

[saip92]

@OnnoGeorg The admin is just for some specific tasks as mentioned in the guide you linked.

1. Creating a database (PUT /database)
2. Deleting a database (DELETE /database)
3. Creating a design document (PUT /database/_design/app)
4. Updating a design document (PUT /database/_design/app?rev=1-4E2)
5. Deleting a design document (DELETE /database/_design/app?rev=1-6A7)
6. Triggering compaction (POST /_compact)
7. Reading the task status list (GET /_active_tasks)
8. Restarting the server (POST /_restart)
9. Reading the active configuration (GET /_config)
10. Updating the active configuration (PUT /_config)

But once a DB is created and it has no users/roles, then anyone can access that database (read/write non-design docs).

@peteruithoven In case of cloudant, last I checked, we specify the _reader and _writer roles to DBs specifically to avoid this issue unless you give access to nobody which makes it accessible to unauthenticated users as well.

[OnnoGabriel]

@saip92 You are right. Setting up an admin is not enough to secure CouchDB.

You also have to disable anonymous access by setting require_valid_user = true in the local.ini configuration file.

At least, I did this and my user databases are not open to public. Only a valid superlogin user has access to his/her database (and only to this), after login and using the retrieved access token provided by superlogin.

[clariontools]

@OnnoGeorg - See my comments on #179 and in a related matter #186. Based on my testing I set require_valid_user = true on both the chttpd and couch_httpd_auth sections in the CouchDB configuration file and it still does not protect the user private dbs when there are no entries in either the Members Users or Roles _security document of the private dbs. This should be the case when the db is created and when the user logs out as the active session is deleted.

EDIT: October 8, 2017, I have to clarify this further because setting the 'require_valid_user' properties on chttpd and couch_http_auth sections to true does force a valid user, it DOES NOT force any specific user to a specific private user specific db. The subtlety here is that a user private db that has no sessions active (and no roles) will still require a valid _user, but it will allow ANY valid user from the _users db. SO while I could not access a db without a valid user and password, if I have my own token I could easily access any other users db (when they are fully logged out). So...

Only a valid superlogin user has access to his/her database (and only to this)

This is not true, if I grab my token and hit another users private db (as long as I have their name) where they are completely logged out, then I could easily access their db with my token.

[saip92]

@OnnoGeorg I guess it didn't fully read your comment before.

What @clariontools mentioned is right and despite the measures you have taken, it still leaves private DBs open to other valid users, assuming they have a basic understanding of couchdb/superlogin and have a target username, which is most likely public information depending on your application/website.

Especially if they figure out you are using superlogin (and come across this issue 😨), it would be pretty simple for someone to mess with things.

[ymandaokar]

Default behaviour of CouchDB, if there is NO member in a DB, it becomes public. On user login CouchDB added its default member and after user logout it removes it. So, your db will become public and accessible if you are not logged-in. To prevent this, add at least one member on superlogin config file.

[dantman]

I think the easiest fix would be to add a role 'user:' to each of the private databases on register.

IMHO this is just how it should work period. SuperLogin already automatically adds the user:foo role to the _user. Which means that using user:foo as a member role should automatically work to give access to a database. In fact it IMHO would be better than the way SuperLogin currently works because then SuperLogin would not need to update _security every time a user logs in or a session is removed.

Edit: That would also fix #145