CAPEC Definitions / CAPEC-676
CAPEC-676: NoSQL Injection
An adversary targets software that constructs NoSQL statements based on user input or with parameters vulnerable to operator replacement in order to achieve a variety of technical impacts such as escalating privileges, bypassing authentication, and/or executing code.
Extended Description
NoSQL database calls are written in an application's programming language, via a custom API call, or formatted in a common convention (e.g., JSON, XML, etc.), any of which the adversary can exploit to achieve the aforementioned goals. NoSQL attacks usually result from improper sanitization and validation of data that originates from a user, either via special character or JavaScript injection. In both cases, the adversary crafts input strings so that when the target software constructs NoSQL statements based on the input, the resulting NoSQL statement performs actions other than those intended by the application. However, unlike traditional SQL Injection attacks, NoSQL injection attacks can also occur in instances where the application does not rely upon user input, as is the case in operator replacements. This entails the adversary overriding reserved NoSQL variable names with ones that have been modified with malicious functionality (e.g., $where in MongoDB). In all cases, depending on the NoSQL API and data model used, successful injection can cause information disclosure, data modification, and code execution at the application level. Note: NoSQL Injection attacks are executed within a procedural language (e.g., C, C++, Perl), as opposed to the declarative SQL language itself. As a result, NoSQL injection attacks can potentially result in greater impacts than traditional SQL Injection attacks [REF-668].
Mitigations
Strong input validation - All user-controllable input must be validated and filtered for illegal characters as well as relevant NoSQL and JavaScript content. NoSQL-specific keywords, such as $ne, $eq or $gt for MongoDB, must be filtered in addition to characters such as a single-quote(') or semicolons (;) based on the context in which they appear. Validation should also extend to expected types.
If possible, leverage safe APIs (e.g., PyMongo and Flask-PyMongo for Python and MongoDB) for queries as opposed to building queries from strings.
Ensure the most recent version of a NoSQL database and it's corresponding API are used by the application.
Use of custom error pages - Adversaries can glean information about the nature of queries from descriptive error messages. Input validation must be coupled with customized error pages that inform about an error without disclosing information about the database or application.
Exercise the principle of Least Privilege with regards to application accounts to minimize damage if a NoSQL injection attack is successful.
If using MongoDB, disable server-side JavaScript execution and leverage a sanitization module such as mongo-sanitize.
If using PHP with MongoDB, ensure all special query operators (starting with $) use single quotes to prevent operator replacement attacks.
Additional mitigations will depend on the NoSQL database, API, and programming language leveraged by the application.
Relationships with other CAPECs
CAPEC-248: Command Injection
Prerequisites
Awareness of the technology stack being leveraged by the target application.
NoSQL queries used by the application to store, retrieve, or modify data.
User-controllable input that is not properly validated by the application as part of NoSQL queries.
Target potentially susceptible to operator replacement attacks.
