Co-authored by Emanuel Bronshtein

Are you using one of the trending NoSQL databases such as MongoDB or CouchDB? Or maybe you are thinking of using one of those but are troubled by how secure they are? We will discuss the security of the application programming interfaces (APIs) and software development kits (SDKs) of NoSQL databases, while also diving into the application code consuming these databases and providing some examples and advice on the risks and mitigations.

NoSQL Databases Still Have Risks

NoSQL, which stands for Not Only SQL, is a common term for nonrelational databases. Among popular NoSQL databases you will find the aforementioned MongoDB and CouchDB, along with Redis, Cassandra and more. NoSQL databases have become increasingly popular thanks to their benefits in particular use cases, especially in big data and real-time Web usages where performance, scalability and flexibility are key.

Database security has been and will continue to be one of the more critical aspects of application security. Access to the database grants an attacker a dangerous amount of control over the most critical information. Although the number of SQL injection vulnerabilities has been declining since 2008 due to use of secure frameworks and improved awareness, it has remained a high-impact risk.

With the emergence of new databases and query techniques, the old attack methods become obsolete and new ones emerge. For example, most NoSQL databases do not use SQL and instead use the JavaScript Object Notation (JSON) query language and an HTTP API. This makes old techniques like SQL injection obsolete. However, NoSQL definitely does not imply zero risk. In fact, NoSQL databases are vulnerable to injection attacks, cross-site request forgery (CSRF) and other vulnerabilities.

In a paper we presented at the Web 2.0 Security and Privacy conference titled “No SQL, No Injection? Examining NoSQL Security,” we demonstrated a number of techniques for injections in different runtimes using MongoDB. Additionally, the paper discusses Web APIs and their risks, such as CSRF, and some deployment recommendations. We recommend reading the paper, which includes actual code samples of possible exploits.

Knowing the risks is key for protecting against them. Having automated security testing is also significant for achieving consistent results. Web application scanners, for instance, can use rules for finding vulnerabilities in NoSQL databases to help you protect against the new exploitation techniques.

Examples of NoSQL Exploits

For those of you who prefer to get more technical, here are a few examples of exploits. More are fleshed out in the full paper.

Consider the following situation: A PHP application has a login mechanism where the username and password are sent from the user’s browser via HTTP POST. This vulnerability is applicable to HTTP GET, as well. A typical POST payload would look like:

username=tolkien&password=hobbit

The backend PHP code to process it and query MongoDB for the user would look like:

db->logins->find(

array(

“username”=>$_POST[“username”],

“password”=>$_POST[“password”]

);

But PHP has a built-in mechanism for associative arrays that allows an attacker to send the following malicious payload:

username[$ne]=1&password[$ne]=1

PHP translates this input into:

array(

“username” => array(“$ne” => 1),

“password” => array(“$ne” => 1)

);

MongoDB keywords start with a dollar sign and, specifically in this example, $ne is the keyword for the not equals operator, which means select all documents where username is not equal to 1 and password is not equal to 1.

To mitigate this issue, cast the parameters received from the request to the proper type, in this case string:

db->logins->find(

array(

“username”=>(string)$_POST[“username”],

“password”=>(string)$_POST[“password”]

);

Another language-agnostic example that is one of the common reasons for SQL injections stems from building the query from string literals, which include user input without proper encoding. The JSON query structure makes this harder to achieve in modern data stores such as MongoDB. Nevertheless, it is still possible. Let’s examine a login form that sends its username and password parameters via an HTTP POST to the back end, which constructs the query by concatenating strings. For example, the developer would do something like:

string query =

“{ username: ‘” + post_username + “‘, password: ‘” + post_password + “‘ }”

With malicious input, this query can be turned to ignore the password, allowing the attacker to log into a user account without the password. An example for malicious input:

Username: tolkien’, $or: [ {}, { ‘a’:’a

Password:‘ } ], $comment:’successful MongoDB injection’

Without encoding, this input will be constructed into the following query:

username: ‘tolkien’,

$or: [ {}, { ‘a’: ‘a’, password: ” } ],

$comment: ‘successful MongoDB injection’

That is, the password becomes a redundant part of the query because an empty query {} is always true and the comment in the end does not affect it. Today, every language has good native libraries for JSON encoding, so there is no reason to construct JSON queries from strings. For more examples and information on other risks such as CSRF, we recommend you read the complete paper.

More from Application Security

Kronos Malware Reemerges with Increased Functionality

The Evolution of Kronos Malware The Kronos malware is believed to have originated from the leaked source code of the Zeus malware, which was sold on the Russian underground in 2011. Kronos continued to evolve and a new variant of Kronos emerged in 2014 and was reportedly sold on the darknet for approximately $7,000. Kronos is typically used to download other malware and has historically been used by threat actors to deliver different types of malware to victims. After remaining…

Self-Checkout This Discord C2

This post was made possible through the contributions of James Kainth, Joseph Lozowski, and Philip Pedersen. In November 2022, during an incident investigation involving a self-checkout point-of-sale (POS) system in Europe, IBM Security X-Force identified a novel technique employed by an attacker to introduce a command and control (C2) channel built upon Discord channel messages. Discord is a chat, voice, and video service enabling users to join and create communities associated with their interests. While Discord and its related software…

A View Into Web(View) Attacks in Android

James Kilner contributed to the technical editing of this blog. Nethanella Messer, Segev Fogel, Or Ben Nun and Liran Tiebloom contributed to the blog. Although in the PC realm it is common to see financial malware used in web attacks to commit fraud, in Android-based financial malware this is a new trend. Traditionally, financial malware in Android uses overlay techniques to steal victims’ credentials. In 2022, IBM Security Trusteer researchers discovered a new trend in financial mobile malware that targets…

Twitter is the New Poster Child for Failing at Compliance

All companies have to comply with privacy and security laws. They must also comply with any settlements or edicts imposed by regulatory agencies of the U.S. government. But Twitter now finds itself in a precarious position and appears to be failing to take its compliance obligations seriously. The case is a “teachable moment” for all organizations, public and private. The Musk Factor Technology visionary and Silicon Valley founder and CEO, Elon Musk, bought social network Twitter in October for $44…