Introduction to NoSQL Injection

Preventing NoSQL Injection Vulnerabilities

Introduction

NoSQL injection vulnerabilities arise when user input is passed into a NoSQL query without being properly sanitized first. Let's walk through the four examples we covered in the last 'chapter' and explain what went wrong and how to fix them.

String Casting with Input Validation

MangoMail

In the case of MangoMail, this is what the vulnerable code looked like on the server side:

...
    if ($_SERVER['REQUEST_METHOD'] === "POST"):
        if (!isset($_POST['email'])) die("Missing `email` parameter");
        if (!isset($_POST['password'])) die("Missing `password` parameter");
        if (empty($_POST['email'])) die("`email` can not be empty");
        if (empty($_POST['password'])) die("`password` can not be empty");

        $manager = new MongoDB\Driver\Manager("mongodb://127.0.0.1:27017");
        $query = new MongoDB\Driver\Query(array("email" => $_POST['email'], "password" => $_POST['password']));
        $cursor = $manager->executeQuery('mangomail.users', $query);
        
        if (count($cursor->toArray()) > 0) {
            ...

We can see that the problem is $_POST['email'] and $_POST['password'] are passed directly into the query array without sanitization, leading to a NoSQL injection which we were able to exploit to bypass authnetication.

MongoDB is strongly-typed, meaning if you pass a string, MongoDB will interpret it as a string (1 != "1"). This is unlike PHP (7.4), which is weakly-typed and will evaluate 1 == 1 as true. Since both email and password are expected to be string values, we can cast the user input to strings to avoid anything arrays being passed.

...
$query = new MongoDB\Driver\Query(array("email" => strval($_POST['email']), "password" => strval($_POST['password'])));
...

Now queries like email[$ne]=x will be cast to "Array" and the attack will fail.

[!bash!]$ php -a

Interactive mode enabled

php > echo strval(array("op" => "val"));
PHP Notice:  Array to string conversion in php shell code on line 1
Array

This by itself prevents the NoSQL injection attack from working; however, it would be a good idea to additionally verify that email matches the correct format (to avoid future vulnerabilities/errors). In PHP you can do that like this:

...
if (!filter_var($email, FILTER_VALIDATE_EMAIL)) {
    // Invalid email
    ...
}
// Valid email
...

MangoPost

On the back end, MangoPost looks slightly different, but it is again the same problem and the same solution.

...
if ($_SERVER['REQUEST_METHOD'] === "POST") {
    $json = json_decode(file_get_contents('php://input'));

    $manager = new MongoDB\Driver\Manager("mongodb://127.0.0.1:27017");
    $query = new MongoDB\Driver\Query(array("trackingNum" => $json->trackingNum));
    $cursor = $manager->executeQuery('mangopost.tracking', $query);
    $res = $cursor->toArray();
    
    if (count($res) > 0) {
        echo "Recipient:          " . $res[0]->recipient . "\n";
        echo "Address:            " . $res[0]->destination . "\n";
        echo "Mailed on:          " . $res[0]->mailedOn . "\n";
        echo "Estimated Delivery: " . $res[0]->eta;
    } else {
        echo "This tracking number does not exist";
    }

    die();
}
...

Cast to a string!

...
$query = new MongoDB\Driver\Query(array("trackingNum" => strval($json->trackingNum)));
...

Tracking numbers most likely have a format they follow, so in addition to this cast, we should probably verify that. Let's imagine tracking numbers can contain upper/lowercase letters, digits, and curly braces (/^[a-z0-9\{\}]+$/i). We could create a RegEx to match this and verify tracking numbers like this:

...
if (!preg_match('/^[a-z0-9\{\}]+$/i', $trackingNum)) {
    // Invalid tracking number
    ...
}
// Valid tracking number
...

String Casting without Input Validation

MangoSearch

The problem in MangoSearch is the same - the query parameter $_GET['q'] is passed without sanitization into the query array, leading to NoSQL injection.

...
if (isset($_GET['q']) && !empty($_GET['q'])):
    $manager = new MongoDB\Driver\Manager("mongodb://127.0.0.1:27017");
    $query = new MongoDB\Driver\Query(array("name" => $_GET['q']));
    $cursor = $manager->executeQuery('mangosearch.types', $query);
    $res = $cursor->toArray();
    foreach ($res as $type) {
        ...

Just like in MangoMail, the value of name is expected to be a string, so we can cast $_GET['q'] to a string to prevent the NoSQLi vulnerability.

...
$query = new MongoDB\Driver\Query(array("name" => strval($_GET['q'])));
...

Query Rewriting

MangoOnline

Unlike the previous three examples, simply casting to a string will not work in the case of MangoOnline since the exploit did not involve any arrays. As a quick reminder, this is what the back-end code looks like:

if ($_SERVER['REQUEST_METHOD'] === "POST") {
    $q = array('$where' => 'this.username === "' . $_POST['username'] . '" && this.password === "' . md5($_POST['password']) . '"');

    $manager = new MongoDB\Driver\Manager("mongodb://127.0.0.1:27017");
    $query = new MongoDB\Driver\Query($q);
    $cursor = $manager->executeQuery('mangoonline.users', $query);
    $res = $cursor->toArray();
    if (count($res) > 0) {
        ...

The best option, in this case, is to convert the MongoDB query into one that doesn't evaluate JavaScript while not introducing new vulnerabilities. In this case, it is quite simple:

if ($_SERVER['REQUEST_METHOD'] === "POST") {
    $manager = new MongoDB\Driver\Manager("mongodb://127.0.0.1:27017");
    $query = new MongoDB\Driver\Query(array('username' => strval($_POST['username']), 'password' => md5($_POST['password'])));
...

According to the developers of MongoDB, you should only use $where if it is impossible to express a query any other way.

If you don't use any queries which evaluate JavaScript in your project, then a good idea would be to completely disable server-side JavaScript evaluation, which is enabled by default.

Conclusion

These steps patched the four vulnerable websites against NoSQL injections. Traditional SQL databases have parameterized queries which are an excellent way to prevent injection but preventing MongoDB / NoSQL injection is not as simple. The best you can do as a developer is:

Never use raw user input. Always sanitize, for example, with a white list of acceptable values.
Avoid using JavaScript expressions as much as possible. Most queries can be written with regular query operators.

Previous Next

Tools of the Trade

Defending against NoSQL Injection

Preventing NoSQL Injection Vulnerabilities

Skills Assessment

Skills Assessment I Skills Assessment II

My Workstation

OFFLINE

/ 1 spawns left

Cheat Sheet

The cheat sheet is a useful command reference for this module.

MongoDB Usage

Connect to MongoDB: mongosh mongodb://127.0.0.1:27017
List databases: show databases
List collections: show collections
Insert data: db.collection.insertOne({...})
Insert lots of data: db.apples.insertMany([{...},{...},...])
Selecting data: db.collection.find({...})
Selecting one piece of data: db.collection.findOne({...})
Update (one) document: db.collection.updateOne({...}, {...})
Update multiple documents: db.collection.updateMany({...}, {...})
Delete document(s): db.apples.remove({...})

Query Operators

Type	Operator	Description	Example
Comparison	`$eq`	Matches values which are `equal to` a specified value	`type: {$eq: "Pink Lady"}`
Comparison	`$gt`	Matches values which are `greater than` a specified value	`price: {$gt: 0.30}`
Comparison	`$gte`	Matches values which are `greater than or equal to` a specified value	`price: {$gte: 0.50}`
Comparison	`$in`	Matches values which exist `in the specified array`	`type: {$in: ["Granny Smith", "Pink Lady"]}`
Comparison	`$lt`	Matches values which are `less than` a specified value	`price: {$lt: 0.60}`
Comparison	`$lte`	Matches values which are `less than or equal to` a specified value	`price: {$lte: 0.75}`
Comparison	`$nin`	Matches values which are `not in the specified array`	`type: {$nin: ["Golden Delicious", "Granny Smith"]}`
Logical	`$and`	Matches documents which `meet the conditions of both` specified queries	`$and: [{type: 'Granny Smith'}, {price: 0.65}]`
Logical	`$not`	Matches documents which `do not meet the conditions` of a specified query	`type: {$not: {$eq: "Granny Smith"}}`
Logical	`$nor`	Matches documents which `do not meet the conditions` of any of the specified queries	`$nor: [{type: 'Granny Smith'}, {price: 0.79}]`
Logical	`$or`	Matches documents which `meet the conditions of one` of the specified queries	`$or: [{type: 'Granny Smith'}, {price: 0.79}]`
Evaluation	`$mod`	Matches values which divided by a `specific divisor` have the `specified remainder`	`price: {$mod: [4, 0]}`
Evaluation	`$regex`	Matches values which `match a specified RegEx`	`type: {$regex: /^G.*/}`
Evaluation	`$where`	Matches documents which `satisfy a JavaScript expression`	`$where: 'this.type.length === 9'`

Authentication Bypass / Data Exfiltration Payloads:

URL-Encoded

param[$ne]=x
param[$gt]=
param[$gte]=
param[$lt]=~
param[$lte]=~
param[$regex]=.*

JSON

{param: {$ne: 'x'}}
{param: {$gt: ''}}
{param: {$gte: ''}}
{param: {$lt: '~'}}
{param: {$lte: '~'}}
{param: {$regex: '.*'}}
{param: {$nin: []}}

Blind NoSQLi Payloads:

URL-Encoded

param[$regex]=^XYZ.*$

JSON

{param: {$regex: '^XYZ.*$}}

Server-Side JavaScript Injection Payloads:

' || true || ''=='
" || true || ""=="

This cheat sheet contains a (non-comprehensive) list of payloads you may use when testing an application for NoSQL injection vulnerabilities. The most important qualities for finding vulnerabilities are creativity and the ability to adapt, so it is possible that these payloads will not work in your specific scenario, but something else does.

Some other resources you may want to refer to may be:

Introduction to NoSQL Injection

Preventing NoSQL Injection Vulnerabilities

Introduction

String Casting with Input Validation

MangoMail

MangoPost

String Casting without Input Validation

MangoSearch

Query Rewriting

MangoOnline

Conclusion

Table of Contents

Introduction

Basic NoSQL Injection

Blind Data Exfiltration

Tools of the Trade

Defending against NoSQL Injection

Skills Assessment

My Workstation