code

NoSQL Injection

Written by Sagiv Michael on

NoSQL Injection

Written by Sagiv Michael on


Introduction

As organizations embrace the scalability and flexibility offered by NoSQL (Not Only SQL) databases, they must be aware of the potential security vulnerabilities they may introduce. One such vulnerability is NoSQL Injection, which can significantly affect data integrity and application security. This article dives into the concept of NoSQL Injection, its impact on databases, and practical strategies to mitigate the associated risks, ensuring the robustness of your data management systems.

NoSQL Database

NoSQL, or non-SQL databases refer to non-relational databases that utilize diverse data models. Unlike traditional relational databases, NoSQL databases do not organize data into structured tables with predefined schemas. Instead, they employ various data types such as key-value, key-document, column-family, and graph databases. In today’s data-centric world, NoSQL databases, with MongoDB as a prominent example, have gained significant popularity.

While NoSQL databases do not support SQL statements or queries like their SQL counterparts, they still provide methods for executing queries. However, there are notable differences in the query language and syntax between NoSQL and SQL databases. Each NoSQL database product has its specific query format closely tied to the implementation of the web application or API. Consequently, the queries will vary depending on the chosen database, programming language (e.g., Python, PHP, Node.js), and framework (e.g., Spring).

In most cases, NoSQL queries are based on JSON and frequently involve user input. However, because JSON-based queries are considered unsanitized user inputs, NoSQL databases are susceptible to injection attacks. These vulnerabilities arise due to the absence of proper input validation and sanitization mechanisms, exposing the databases to potential exploitation.

Overall, the flexibility and scalability of NoSQL databases have contributed to their widespread adoption. However, organizations must be mindful of the security risks associated with NoSQL databases, particularly the vulnerability to injection attacks resulting from unsanitized user inputs in JSON-based queries.

Explanation of The Attack

NoSQL Injection attack is a security vulnerability that arises when untrusted user input is improperly handled within NoSQL queries or commands. Like SQL Injection, NoSQL Injection occurs when attackers exploit the lack of input validation or sanitization in NoSQL database operations, enabling them to manipulate queries and access unauthorized data. By injecting malicious or unexpected input, attackers can modify the behavior of queries, execute unauthorized commands, or extract sensitive information from the database.

NoSQL Injection Attacks

To gain a better understanding of how NoSQL queries work and where they can be vulnerable to injection attacks, let’s examine  MongoDB, the most popular NoSQL database. In the following example, we will utilize PHP to access MongoDB and demonstrate a simple example to implement authentication:

$username = $_POST[‘username’];
$password = $_POST[‘password’];
$connection = new MongoDB\Client(‘mongodb://localhost:27017’);
if ($connection) {
$db = $connection->test;
$users = $db->users;
$query = array(“user” => $username, “password” => $password);
$req = $users->findOne($query);
}

In the above example, the username and password parameters used for authentication are taken directly from a POST request, and are inserted into the query without proper sanitization. Using this syntax renders the application susceptible to NoSQL Injection attacks, allowing an attacker to enter a payload that grants them unauthenticated access. This result is similar to other forms of injection attacks as well.

To execute a successful MongoDB NoSQL Injection, simply including the following operators in the POST request is sufficient:

username[$eq]=admin&password[$ne]=foo

The purpose of utilizing the [$ne] operator in the query is to enable an  “admin” user with any password which is different than  “foo”, to log in successfully. Therefore, if this code is used for authenticationת and there is an admin user with a password different than “foo”, it will be possible for an attacker to exploit this attack to authenticate as that user successfully.

Other MongoDB operators, such as [$lt], [$gt], and [$regex], can be manipulated similarly. In summary, by utilizing regular expressions, attackers can enumerate all users by attempting various combinations in a sequence of commands and evaluating the outcomes.

Advanced NoSQL Injection

The usage of $where operator in MongoDB queries introduces the potential for severeNoSQL attacks, including exploiting JavaScript objects. Here is an example of the common usage of the $where operator by a developer who wishes to access a user-specific record:

$query = array('$where' => 'this.name === \''.$name.'\'');

In this case, an attacker could use the following empty string comparison trick by injecting the following statement into the $name parameter:

'; return '' == '

As a result, the query will become:

"$where": "this.name === ''; return '' == ''"

Since the result is always true, the attacker can access the entire user list successfully.

Moreover, the utilization of the $where operator presents another avenue of exploiting the system by disguising malicious code as JavaScript. An attacker can pass the following code, containing a parameter with a crafted string:

'; while(true){}'

This example demonstrates the potential risks related to the NoSQL MongoDB queries. The vulnerability exists within the $where operator, allowing an attacker to inject the above string. This method initiates an endless loop, resulting in a significant strain on system resources. This heavy load causes the system to become unresponsive and therefore significantly threatens the system’s overall availability.

Mitigation

If you have encountered any of the above scenarios, please follow to instructions below provided by Clear Gate for immediate mitigation and to prevent JSON Injection attacks further:

  • Use a suitable sanitization library, such as Mongo-sanitize or Mongoose for MongoDB.
  • If you can’t find a library for your environment, cast user input to the expected type. For example, cast usernames and passwords to strings.
  • If you using MongoDB, never directly combine the where, mapReduce, or group operators with user input. As detailed above, this combination poses a great risk since it allows attackers to inject JavaScript. For extra safety, set javascriptEnabled to false in mongod.conf whenever possible.
  • Unlike many other web vulnerabilities, NoSQL Injections can be caused by insecure web application code and vulnerabilities in NoSQL databases. Therefore, always use the latest versions of NoSQL databases to reduce the risk. Aim to immediately fix known vulnerabilities, for example, in MongoDB.Given that NoSQL databases are relatively new technology compared to SQL databases, and since there is a wide range of available options, it is essential to note that the potential for developer error is significantly higher. To minimize the risk, always follow the principle of running your machine with the lowest privileges possible. In that way, you can ensure that even during a successful attack, access to other server-side resources will not be achieved.

Conclusion

NoSQL databases, with their unique query formats and reliance on specific database products, programming languages, and frameworks, introduce vulnerabilities to injection attacks. Using JSON-based queries, often incorporating unsanitized user inputs, exposes NoSQL databases to the risk of injection attacks. To mitigate these risks, organizations should prioritize security measures such as conducting Cyber Risk Assessments, penetration tests, security audits, IT gap analysis, code reviews, and cloud audits. 

Clear Gate, a trusted cybersecurity provider, offers comprehensive services to help organizations strengthen their NoSQL database security and protect valuable data from potential threats.

References