NoSQL: Injection vaccination for a new generation

This future architecture still falls into some of the same old traps

Programming NoSQL systems

In a previous article I discussed the emergence of SQL-like languages for NoSQL systems, in particular CQL for Cassandra. It seems amazing that the drivers for CQL still let programmers write code that could be vulnerable to SQL-type injection attacks.

The CQL java driver allows the execution of the following insert command:

Session.execute (“Insert into Tablename) values (‘“+Sum Variables”’) – “Sum Variables” could have come from a parameter filled in by a user on a webpage. This is exactly how SQL injection can work and a naive programmer might well pick this up as sample code and decide to use it.

The advice is the same as it is for SQL programmers; use prepared statements or a query builder to avoid this type of problem. In fact, in Cassandra, prepared statements can speed up query execution as they can be stored on the servers and be reused.

There is some evidence that SQL injection-type attacks can be extended to other NoSQL databases that store JSON in their engines. Several security experts have explored the option of using the MongoDB’s $where clause to inject javascript into the JSON for undesirable side effects – a common example is causing the MongoDB machine to execute at 100 per cent CPU cycles.

Two papers from Bryan Sullivan from Adobe highlight this problem and it is something MongoDB operators should be aware of and test for in their systems.

Internode communications

All database systems accessible through a network are vulnerable to attack and should be closely firewalled, but one unique problem that NoSQL systems throw up is the question of internode communication.

If you have a cluster of machines they need to communicate in some manner, and if this is via an open wire with no encryption then your system may be open to wire sniffing using simple tools such as wireshark (and others).

The answer is simple; make sure your internode communication is via SSL and that it’s implemented correctly, with correctly signed certificates. You will also want to check that all internode communication settings in the configuration files are correct and that communication between your nodes and clients is also over a correctly configured SSL channel.

It can be a pain and you may have to make sure the tools that monitor the system are also setup to use SSH, but it is good practice to lock down communications like this.

NoSQL not unique

There is nothing unique about NoSQL systems, and they are as vulnerable to attack vectors as any other system on the internet today. Many of the attack vectors (table security, disk security and possibly SQL injection) are the same as their RDBMS cousins and need to be considered in the same way.

However, given the likelihood that they will be part of a distributed system then consideration for encoding over the wires should be included in any planned deployment.

Even if you aren’t running a traditional database and have implemented some sort of datalake using a distributed file system such as HDFS (Hadoop file system) it may still be open to being compromised.

The documentation for Hadoop 2.7.1 states that Hadoop by default runs in non-secure mode, not a state of affairs you would want to leak into a production system.

We need to be aware that out of the box these systems may not be secure and if you want a secure environment, build it into the system from the start, as leaving it too late may mean leaving it entirely and leaving you open to avoidable hack attack. ®