NoSQL Injection

ID

python.nosql_injection

Severity

critical

Resource

Injection

Language

Python

Tags

CWE:943, NIST.SP.800-53, OWASP:2021:A3, PCI-DSS:6.5.1

Description

Improper Neutralization of Special Elements in Data Query Logic ("NoSQL Injection")

NoSQL Injection exploits weaknesses in applications interacting with NoSQL databases, such as MongoDB or Couchbase, by manipulating input data to alter query execution.

Unlike traditional SQL injections, which rely on SQL syntax, NoSQL injections leverage the flexible, schema-less nature of NoSQL databases.

Rationale

NoSQL databases often provide "query-by-example" capabilities, allowing users to construct queries from JSON without the need for SQL-like syntax. Unfortunately, this flexibility comes with the potential for NoSQL Injection vulnerabilities.

For example, a MongoDB query such as

db.users.find({ username: username, password: password })

could be altered using query and projection operators: username={"gt": ""} and `password={"gt": ""} match to mach any document.

In Python, a common scenario involves directly embedding user input into NoSQL queries. Consider the following example using a MongoDB database:

from pymongo import MongoClient

def get_user_details(username):
    client = MongoClient('mongodb://localhost:27017/')
    db = client['example_db']
    users = db['users']

    # Vulnerable to NoSQL Injection
    user = users.find_one({"username": username})

    return user

Here, if an attacker inputs a JSON-like structure, such as {"$ne": null}, they could manipulate the query to retrieve unintended results, effectively bypassing user identification constraints.

Remediation

To mitigate NoSQL Injection risks in applications, follow these best practices:

  1. Input Validation: Rigorously validate inputs before processing them in NoSQL queries. Apply strict checks on data types, lengths, and formats.

  2. Use of Binding Mechanisms: Prefer using binding mechanisms or parameterized query structures provided by the NoSQL database’s library when assembling queries. This approach helps separate data from query logic.

  3. Sanitization: When using user inputs in query objects, ensure they are sanitized and free from characters or patterns that could be interpreted as part of a query structure. This is hard to do and error-prone, so consider first using binding mechanisms for parameterized queries, when available.

  4. Whitelist Validation: Implement whitelisting for input validation to ensure only expected values are allowed and unexpected input is rejected.

  5. Access Controls and Principle of Least Privilege: Implement strict access controls at the database level, and ensure that applications access only permitted data. Use credentials with the least privileges needed for the functionality.

  6. Regular Security Audits and SAST: Regularly audit your codebase for security vulnerabilities and include SAST tools in your development pipeline to catch potential NoSQL injections early in the development process.

By adopting these measures, you reduce the risk of NoSQL Injection vulnerabilities in your applications, protecting your database’s integrity and confidentiality.

Configuration

The detector has the following configurable parameters:

  • sources, that indicates the source kinds to check.

  • neutralizations, that indicates the neutralization kinds to check.

Unless you need to change the default behavior, you typically do not need to configure this detector.

References