Link Search Menu Expand Document

NoSQL Injection

  1. NoSQL Injection
    1. Description
    2. Impact
    3. Scenarios
    4. Prevention
    5. Testing

image

Description

The rise of use in big data and real-time web applications over the last years has led to a marked increase in the use of NoSQL databases. NoSQL was designed in part as a response to this adoption of more agile design methodologies, allowing for dynamic schema definitions unlike traditional SQL databases.

However, even though the mechanism for data retrieval differs from that of traditional SQL relational databases, security flaws resulting from poorly written code continue to persist since they still serve queries based on user input.

The NoSQL injection is a security vulnerability which, much like a SQL Injection vulnerability, relies on weaknesses exposed by insufficient input validation, allowing an attacker to view or change backend data that they do not have authorisation to access. NoSQL injection can take place at the application layer and those NoSQL Databases using server-side scripting for enhancement purposes are particularly susceptible to attack.

Impact

NoSQL injection is included in the A1-Injection category in the OWASP top 10 Application Security Risks given its high severity and exploitability. A successful NoSQL injection attack can result in a malicious user gaining complete access to all data in a database server with the ability to execute unauthorised queries and compromise the confidentiality, integrity and availability of the application.

Scenarios

The exploitation of this type of vulnerability is highly dependant on the specific NoSQL database in use, and the implementation of the vulnerable code. Well-known exploitation techniques include:

  • The injection of tautologies in conditional statements to generate ‘always true’ expressions and bypass access mechanisms
  • The injection of UNION queries to extract unexpected datasets
  • JavaScript injections to run arbitrary code in the database engine
  • Injecting new queries by inserting additional code through special characters

The following is the classic example of a NoSQL injection that generates an ‘always true’ tautology and bypass a login mechanism.

Assume a web application stores the users’ credentials on MongoDB and checks upon login if a user with the given username and password exists using an injectable Mongo NoSQL query.

Users.findOne(
  {
    "name" : req.body.name, 
    "password" : req.body.password
  }
 );

To authenticate, a legitimate user would submit a JSON object containing the credentials.

{
  "name": "user",
  "password": "password"
}

Since the username parameter comes from a deserialized JSON object, it is possible for an attacker to inject MongoDB query operators to manipulate the query and perform a login bypass.

Instead of sending the intended name and password strings, the injection can be performed sending a JSON object containing MongoDB query operators.

{
  "name": { "$ne": "1"},
  "password": { "$ne": "1"}
}

The query operator $ne (not equal) will be used by the Users.findOne() to find the first User that has a name and password that is not equal to the string "1". Since the statement is true and always returns a valid user, this request enables the attacker to log in without providing the credentials.

Prevention

To avoid NoSQL injection vulnerabilities, developers need to validate user data by identifying unintended data structure, such as objects and arrays, which can be used to inject NoSQL modifiers that can validate or enforce expected types.

Using typed models will convert the user data to the expected type, thus stopping some injections.

Finally, to mitigate potential damage of NoSQL (or any for that matter) injection attacks, developers and admins must consider the type of access rights afforded to an application. Further, privilege minimisation of the operating system account that the database process is running on is good hygiene.

Testing

Verify that data selection or database queries use parameterized queries, ORMs, entity frameworks, or are otherwise protected from database injection attacks.


Table of contents