Security best Practices with Couchbase
Couchbase provides standard security and enterprise features, which allow you to build security in your application. Those features include:
Role-Based Access Control
Control privileges to both administrative activities and data access with fine-grained access control.
Integrate Couchbase into your existing security infrastructure with LDAP, PAM and pluggable authentication support.
The Couchbase SDK’s provide safe programming paradigms through secure connections, encryption and parameterized N1QL query support to help prevent attacks like N1QL injection.
Encryption on the Wire
Protect data as it’s sent from clients to a cluster or when it’s transferred between clusters so that it cannot be intercepted and stolen.
Encryption at rest
Secure data at rest with complete application transparency using preferred encryption capabilities that prevent unauthorized data access.
Track all user activity in a cluster including login attempts so data breach attempts can be identified and stopped.
Core to Edge Security
Security in the Couchbase Data Platform covers all products whether deployed on mobile and embedded devices or in the data center.
Regulation Compliance Support
The Couchbase Data Platform delivers key features needed to support regulations such as PCI, HIPAA and GDPR.
The Couchbase Data Platform Enterprise Edition (Couchbase Server, Couchbase Sync Gateway, Couchbase Lite) is provided to customers as a software bundle to be self-deployed by customers on their choice of hardware or cloud platform. As such, Couchbase and its employees do not have direct access to the data a customer has stored in the Couchbase Data Platform or to any production customer systems. In the course of offering support and services it may be necessary for Couchbase employees to have limited access or visibility to customer production systems or technical log files that we will ask our customers permission for.
Couchbase maintains small engineering data centers co-located with developers for use in product development and testing. The datacenters are secured by a physical key, electronic access key, and/or biometric access reader. Electronic access is logged and monitored at all entry points, with elevated/second access required for datacenters. A video camera records motion and access to the Couchbase datacenter located at Couchbase headquarters. An alarm system is installed at all on-premises datacenters and Couchbase headquarters. Couchbase headquarters is protected by a security station with security personnel at the front desk lobby. Key fob security badges are required for building access and elevator floor access during non-business hours at Couchbase headquarters. Key fob security badges are surrendered and deactivated upon employee termination.
Couchbase enforces the rule of least privilege for IT systems. Access to designated systems is limited to those personnel for whom access is required based on job function. Data on Couchbase customers is restricted to individuals who require system access to perform job functions. Access to all systems is deleted or suspended upon termination of employment. Secure transfer protocols (SFTP, SSH etc.) are used to transfer data from one system endpoint to another.
Endpoint Device Security
Employee computers are password protected and the default configuration for such devices causes the devices to be automatically locked after 10 minutes of inactivity. All employee computers are installed with anti-virus/malware software. Employees are provided with a tool to backup/sync company data to to enterprise cloud storage. Each employee receives a laptop computer with an assigned unique company asset tag for identification. Couchbase employees are required to contact IT in an event of laptop theft or loss.
Couchbase will notify customers of any security breach which involved their data as soon as possible after Couchbase becomes aware of it. This applies to information stored in its own systems as well as the systems of its vendors.
Code Scanning and Vulnerability Monitoring
With every release, Couchbase catalogs all the libraries used in the source code, and performs vulnerability scans to match for publicly known vulnerabilities. Developer code undergoes peer review prior to commit in Github, and additionally third-party security validators periodically analyze code for vulnerabilities. Couchbase also actively monitors changes and updates to the U.S. National Vulnerability Databases, and US-CERT. Any vulnerabilities potentially affecting Couchbase products are marked for the development team to investigate and review as per the CVSS v3 standard, and if applicable, patches are created.
Reporting a Security Vulnerability
If you believe you have discovered a vulnerability, or have otherwise experienced a security problem related to Couchbase, please report this to us. If you are a Couchbase customer, you can open a support ticket to report a vulnerability. If you are not a customer, you can send an email to email@example.com.
Reporting an Issue
To report an issue, please either submit a request or open a JIRA issue. Each procedure associates the issue with an identification number; which can be used for tracking purposes.
All vulnerability-reports should contain as much information as possible, to assist our engineers in investigating the issue. In particular, if possible, please include Common Vulnerability information. This includes:
- A CVSS (Common Vulnerability Scoring System) Score.
- A CVE (Common Vulnerability and Exposures) Identifier.
- Your contact information, including an email-address and phone-number.
Couchbase, Inc. requests that you do not publicly disclose information regarding the reported vulnerability until Couchbase has had the opportunity to analyze and to respond to the report, and itself duly notify key users, customers, and partners.
The amount of time required to validate and resolve a reported vulnerability depends on the complexity and severity of the issue and on the possible presence of third-party dependencies. Couchbase takes all reports seriously, prioritizes their investigation, and publicizes confirmed vulnerabilities in the announcement forum and on the support knowledge-base.
Enterprise Security Alerts
|CVE||Synopsis||Impact (CVSS)||Products||Affects Version||Fix Version||Publish Date|
Port 8092 misses X-XSS protection header.
Some enterprises require that REST API endpoints include security-related headers in REST responses. Headers such as X-Frame-Options and X-Content-Type-Options are generally advisable, however some information security professionals additionally look for X-Permitted-Cross-Domain-Policies and X-XSS-Protection, which are more generally applicable to HTML endpoint, to be included too. These headers are now included in responses from the Couchbase Server Views REST API (port 8092).
Prevent N1QL injection in Sync Gateway via _all_docs startkey, endkey.
An attacker with access to the Sync Gateway's public REST API was able to issue additional N1QL statements and extract sensitive data or call arbitrary N1QL functions through the parameters "startkey" and "endkey" on the "_all_docs" endpoint. By issuing nested queries with CPU-intensive operations they may have been able to cause increased resource usage and denial of service conditions. The _all_docs endpoint is not required for Couchbase Mobile replication and external access to this REST endpoint has been blocked to mitigate this issue.
Recognition: Denis Werner/HiSolutions AG
|Couchbase Sync Gateway||2.1.2||
Memcached "connections" stat block command emits non-redacted username.
The system information submitted to Couchbase as part of a bug report included the usernames for all users currently logged into the system even if the log was redacted for privacy.
This has been fixed so that usernames are tagged properly in the logs and are hashed out when the logs are redacted.
Eventing debug endpoint must enforce authentication.
The eventing service exposes system diagnostic profile via an HTTP endpoint that does not require credentials on a port earmarked for internal traffic only. This has been remedied and now requires valid credentials to access.
The /diag/eval endpoint is not locked down to localhost.
Couchbase Server exposed the '/diag/eval' endpoint which by default is available on TCP/8091 and/or TCP/18091. Authenticated users that have 'Full Admin' role assigned could send arbitrary Erlang code to the 'diag/eval' endpoint of the API and the code would subsequently be executed in the underlying operating system with privileges of the user which was used to start Couchbase.
Erlang cookie uses a weak random seed
The cookie used for intra-node communication was not generated securely. Couchbase Server uses erlang:now() to seed the PRNG which results in a small search space for potential random seeds that could then be used to brute force the cookie and execute code against a remote system.
Recognition: Apple Security team
|Couchbase Server||5.1.1||6.0.0||September 2018|
JSON doc with >3k '\t' chars crashes indexer.
Secondary indexing encodes the entries to be indexed using collatejson. When index entries contain certain characters like \t, <, >, it caused buffer overrun as encoded string would be much larger than accounted for, causing indexer service to crash and restart. This has been remedied now to ensure buffer always grows as needed for any input.
Recognition: D-Trust GmbH
XDCR does not validate a remote cluster certificate.
When an invalid Remote Cluster Certificate was entered as part of the reference creation, XDCR did not parse and check the certificate signature. It then accepted the invalid certificate and attempted to use it to establish future connections to the remote cluster. This has been fixed. XDCR now checks the validity of the certificate thoroughly and prevents a remote cluster reference from being created with an invalid certificate.
|Couchbase Server||5.0.0||5.5.0||June 2018|
Editing bucket settings in Couchbase Server allows authentication without credentials.
In versions of Couchbase Server prior to 5.0, the bucket named "default" was a special bucket that allowed read and write access without authentication. As part of 5.0, the behavior of all buckets including "default" were changed to only allow access by authenticated users with sufficient authorization. However, users were allowed unauthenticated and unauthorized access to the "default" bucket if the properties of this bucket were edited. This has been fixed.
How can we help you?
All fields must be filled out unless marked (optional)