What is NoSQL Injection Attack and How to Prevent It?

by Ritika Singh on March 9, 2021

SQL Injections (SQLi) are one of the most dangerous and common vulnerabilities in existence. In the past few years, however, NoSQL databases have risen in popularity as back-end databases for web applications and distributed cloud platforms owing to ease of use and scalability. Given that SQL queries are not performed in these NoSQL (non-SQL/ not only SQL) databases, does that mean non-SQL databases are not vulnerable to injection attacks? Unfortunately, No.

So, how to prevent NoSQL? Let us begin with an overview of NoSQL injection.

What is NoSQL Injection?

NoSQL Databases

NoSQL is a broad term used to refer to non-relational databases/ data storage systems that do not use SQL query language. Some examples are MongoDB, Cassandra DB, CouchDB, and Riak. Of these, MongoDB is the most popular database.

While SQL databases are stored in tables, a multiplicity of data models that are better suited to the purposes/ contexts are used in non-SQL data storage systems. For instance, objects, documents, graphs, key-values, column families, and many more. Given that dynamic schema definitions are supported, new fields and data can be added/ modified with ease as per the agile development cycles, unlike SQL databases.

NoSQL Injection

Cyber-attacks where malicious payload is injected into non-SQL databases, such as MongoDB, are called NoSQL Injection.

Sponsorships Available

How do NoSQL Injection Works?

SQL Injection is caused when queries (especially from users) are un-sanitized, allowing the database engine to be modified by the attacker to include malicious inputs that execute commands in the database. However, SQLi cannot be performed on non-SQL databases since they do not have a specific language. They have product-specific grammar and query syntaxes, which are written in the application language itself.

The result – Not only can the NoSQL databases be breached by attackers, but malicious code/ unvalidated inputs can be executed in the application itself. So, DDoS attacks can be orchestrated, or servers were taken over or confidential user information compromised by attackers by exploiting non-SQL injection vulnerabilities.

In a typical NoSQL architecture, data access is done via drivers. Libraries in multiple languages for the DB client are made available through drivers – access protocol. Considering the drivers may not be vulnerable, but unsafe APIs may be present in them, which if implemented insecurely by developers can open possibilities for arbitrary code execution on the database and the application itself.

Let us consider the example of MongoDB.

BSON (Binary JSON) data format with a secure BSON query assembly tool is used in MongoDB. Given that the queries are represented as BSON objects/ binary data, direct injections are not possible.
Applications, however, are enabled to run JavaScript within the group, $where, and MapReduce operations on the server in MongoDB, including a potential injection vector in the database.
When this functionality is enabled, the developers must ensure that malicious JavaScript cannot be submitted by users.
Even though attackers cannot inject completely arbitrary code, injection of unvalidated inputs using the limited set of functions is sufficient to orchestrate attacks.

For example:

The code snippet below, which uses $where query operator retrieves the record with name ‘Rafael Silver’.

No SQL 1

Here the attacker can insert unsanitized user input through the variable $userData

No SQL 2

If the injection were successful, he might then inject the string, ‘a’; sleep (5000) into the variable $userData, which would pass the server for 5 seconds – this is enough for the attacker to execute what he needs.

NoSQL 3

How to Prevent NoSQL Injections?

1. Secure Coding Practices

The risk of insecure coding is exacerbated because these databases are still new and novel for several developers who are only familiar with SQL and relational databases. The security guidelines and manuals for NoSQL databases must be read carefully and thoroughly. The developers must understand the language being used to ensure that vulnerable constructs are avoided.

Developers must choose the latest available versions of these rapidly developing and young databases. For instance, the initial versions of the popular MongoDB were insecure by design on several levels, leading to lethal injection attacks while the latest versions have been strengthened on the security front.

2. Input Validation

As with SQL Injections, un-sanitized user inputs must be avoided in application code while building database queries. All user inputs must be validated to ensure that malicious values are not used.

While in-built features are available in non-SQL databases like MongoDB to avoid JavaScript in database queries, if JavaScript is unavoidable, input validation is a must.

3. Least Privilege Policy

As a rule, in web application security, the principle of least privilege must be followed. This way, the reach of attackers, in case of successful attacks, can be limited.

Conclusion

NoSQL ≠ No Injection attacks. Non-SQL databases are vulnerable to dangerous and damaging attacks, which must be proactively prevented. Even with the best-efforts during development and deployment, vulnerabilities may remain in the application, causing the risk of non-SQL injections to increase. Onboarding a comprehensive, intelligent, and managed security solution like AppTrana will be valuable in pre-empting attacks and strengthening application security.