Security in applications

Security in applications

To provide for security in applications, pay attention to the client configuration cache and user input validation.

Important: It is a security best practice not to include sensitive information as a part of the document ID.

Client configuration cache

The majority of the Couchbase clusters are running in a steady state most of the time, which means that the cluster nodes are not removed or added very often. Since clients only infrequently receive an update from the cluster whose topology is changing, cluster information is well suited for caching.

When the client is instantiated, it looks for a cached named file in the file system. If the file is there, the client assumes that it belongs to a current cluster configuration and starts using it. If it isn't there, the client starts a normal bootstrap to get the configuration from the cluster and writes it to a file. Whenever you try to access an item on a node and the node tells you that you tried to communicate to the wrong node, you invalidate the cache and request a new copy of the configuration cache.

To use the configuration cache from PHP, add the following to the file php.ini :
couchbase.config_cache = /tmp 

NoSQL injection

Injection attacks are not limited only to SQL databases. In NoSQL databases they might consist of these actions:
  • Injecting of arbitrary key-value pairts.
  • Changing of the user specified document type.
  • Overriding of important document fields.

Example

 {"user": "will","password":"0asd21$1%", 
  "created":"2012-06-12", "password":"password"}
In this JSON document, the first password field 0asd21$1% is the intended value and the application was supposed to store the hashed value for that particular password field. However, the application developer built concatenation based on the user specified input. As a result, the hashed password is overwritten by the plain-text password. If you try to save this document in Couchbase, you will override the first field with the last supplied value.

Be aware that an attacker might try to inject arbitrary key-value pairs, override a key-value pair, or change the document type (such as from Private to Public ). You must, therefore, protect the input and ensure that field overrides are explicit so that they cannot be changed implicitly by attackers.

Best practices for validating user input prohibit accepting of the user input directly and require that strings be concatenated and sent to the database. This requires you to use a document model that includes Java POJOs or .Net POCOs.