Admin REST lacks security

[mryellow]

The lack of any form of authentication on the Admin REST API worries me.

Relying on restricting this port to local access isn't good enough. Gaining local access would mean gaining the ability to inject dodgy data, channels, ACL and users. Yes at this point your machine is compromised, but why make their lives easy.

[jchris]

The point is to make it easy to attach background processes that want to interact with the data without being constrained by the validation helper functions. Also to be able to Sync from Gateway -> Gateway.

If you want a secure interface, do your document update operations on the public port.

I can see some enhancements along these lines like configuration options to require name and password or an https cert on the private port if you want to do end to end ssl.

[snej]

Been thinking about this. There are definitely configurations where a developer needs to run a privileged app server on another host, but can't ensure that both hosts are on a private secure network. (I think this would be common in hosted situations like AWS or Heroku.) This has come up a couple of times in conversations on the forum/mailing list lately.

For this reason it would be really good to be able to give the admin API a password/secret. It would be pretty easy to implement this, I think, by having the rest.handler class conditionally do a basic auth check on admin-user requests.

[tleyden]

@snej +1 on this, since it would allow avoiding setting up a VPN in many scenarios.

On the downside, it makes it very easy for users to do very insecure operations. (doing basic auth with admin account over non-https)

[snej]

The Gateway could easily enforce that non-local admin access has to use HTTPS.

[mikef-dk]

+1 on this as well. I think this would be absolutely useful.

I've tried to run my app server which handles the authentication / sessions on Google App Engine and struggled with this as well. Ultimately I had to drop the idea and move the app server to the same provider due to a missing authentication of the REST Admin API.

[toddfreese]

+1 on this.

[binhrobles]

+1 on this as well. Rolling out our own authentication strategy and currently whitelisting the Auth Service's server IP range for the reverse proxy in front of the Sync Gateway admin port. Would like to be able to manage security for the port at the Sync Gateway level, though.

[househippo]

Could SG leverage rBAC in CB 5.0.
Have it pass along credentials to CB for yes/no.

[mrjumpy]

+1

[ruaanviljoen]

+1

[ghost]

This is required specially when SG to SG replication runs and don't have VPN connectivity, and want security. Secondly for every data entry endpoint I think authentication must be available.
And the admin port case is even strong when one can add remove or change users.

[mryellow]

@erpankaj22081982 Unfortunately this issue is a prime example of how security must never be an after-thought but simply must be considered from the very start. I have little doubt the technical debt is now so great that this can or will never be changed.

[rajagp]

Related : https://forums.couchbase.com/t/accessing-sync-gateway-admin-from-a-remote-host/16917

[snej]

@mryellow: Security was considered from the very start. We made a deliberate decision to simplify the setup/admin process by not requiring a password on localhost, which is secure enough for most needs.

AFAIK it would still be pretty easy to enable a password on the admin API; it's just never become a critical issue or something requested by a customer. If you feel strongly about it you could submit a PR; IIRC the source file to edit is rest/router.go.

[mryellow]

Security was considered from the very start.

You're replying to this issue from half a decade ago to tell me that security was considered?

The whole thing with this issue was voicing this concern early in an attempt to stop a legacy being formed which would be covered in so much technical debt that there would be no way to ever fix this issue.

The place we currently stand.

We made a deliberate decision to simplify the setup/admin process by not requiring a password on localhost, which is secure enough for most needs.

You made that decision at the same time Google was making the decision to ensure that all internal links were encrypted. This was a post-Snowden world in which you were deciding to leave this completely open.

This was a mistake. No amount of revision of history will make this decision a good one. It remains to be fixed at some point in the future, or will continue to always be an issue until this software is history.

[snej]

You seem very upset about this, so much so that I suspect you may be misunderstanding the situation — your mention of encrypting internal links is irrelevant, and if you think there’s too much technical debt to fix this, you haven’t looked at the code.

The admin API is by default not exposed to the network at all, only to the link-local interface. That provides complete protection against external attacks, which is important for a public-facing component. Yes, code running in the same host as SG can access the admin port, but if an attacker can run code locally you’re already in big trouble. (And yes, someone could override the configuration to bind the admin API to a network interface, in which case they would be responsible for the security implications of what they’d done.)

We could make the admin API secure against even local attack by adding authentication. That’s a good enhancement, and it would be pretty easy to implement (despite your repeated mention of “technical debt”, I don’t see any sign you’re familiar with our source code). It hasn’t been done simply because neither we nor our customers have considered it to be enough of a priority yet. Again, I invite you to spent a few hours adding this feature and sending a PR, since you’re the most excited about it of anyone.

[mryellow]

encrypting internal links is irrelevant,

It's part of the issue. Encryption and authentication.

if you think there’s too much technical debt to fix this, you haven’t looked at the code.

It's on the all the deployments out there side. You can't change the default now, you'll break everything.

only to the link-local interface

As stated in the original comment. "Yes at this point your machine is compromised, but why make their lives easy.".

We could make the admin API secure against even local attack by adding authentication.

Would have been easier at the start. This is my point about having to think about it and implement it fro the beginning rather than think you'll do it later. It will never be done later.

don’t see any sign you’re familiar with our source code

The ease at which the source code can be changed is not the issue. It's the deployments which have to adjust to any changes there.

It hasn’t been done simply because neither we nor our customers have considered it to be enough of a priority yet.

Which has been a mistake. I see several posts above from people who seem to think it should have been a priority. Perhaps like myself they're not your customers because they found other solutions instead.

Again, I invite you to spent a few hours adding this feature and sending a PR, since you’re the most excited about it of anyone.

Too late.

[ghost]

Thought this was an issue until we realized the Public API and Admin API can be separated. Made a comment and then deleted it. Very happy with the security configuration of CouchDB so far, although it did throw off our security auditing team for a moment since they didn't have intimate knowledge of the product.

Makes perfect sense. If localhost is compromised, so is everything else. We just stuffed it in a Docker container and said good bye.

[adamcfraser]

Moved to https://issues.couchbase.com/browse/CBG-641