| Name |
NoSQL Injection |
|
| Likelyhood of attack |
Typical severity |
| High |
High |
|
| Summary |
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. |
| 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. |
| Execution Flow |
| Step |
Phase |
Description |
Techniques |
| 1 |
Explore |
[Survey target application] Due to the number of NoSQL databases available and the numerous language/API combinations of each, the adversary must first survey the target application to learn what technologies are being leveraged and how they interact with user-driven data. |
- Determine the technology stack leveraged by the target application, such as the application server, drivers, frameworks, APIs, and databases being utilized.
- Identify areas of the application that interact with user input and may be involved with NoSQL queries.
|
| 2 |
Experiment |
[Identify user-controllable input susceptible to injection] After identifying the technology stack being used and where user-driven input is leveraged, determine the user-controllable input susceptible to injection such as authentication or search forms. For each user-controllable input that the adversary suspects is vulnerable to NoSQL injection, attempt to inject characters or keywords that have special meaning in the given NoSQL database or language (e.g., "$ne" for MongoDB or "$exists" for PHP/MongoDB), or JavaScript that can be executed within the application. The goal is to create a NoSQL query with an invalid syntax. |
- Use web browser to inject input through text fields or through HTTP GET parameters.
- Use a web application debugging tool such as Tamper Data, TamperIE, WebScarab,etc. to modify HTTP POST parameters, hidden fields, non-freeform fields, etc.
- Use network-level packet injection tools such as netcat to inject input
- Use modified client (modified by reverse engineering) to inject input.
|
| 3 |
Experiment |
[Experiment with NoSQL Injection vulnerabilities] After determining that a given input is vulnerable to NoSQL Injection, hypothesize what the underlying query looks like. Iteratively try to add logic to the query to extract information from the database, modify/delete information in the database, or execute commands on the server. |
- Use public resources such as OWASP's "Testing for NoSQL Injection" [REF-668] or Null Sweep's "NoSQL Injection Cheatsheet" [REF-669] and try different approaches for adding logic to NoSQL queries.
- Iteratively add logic to the NoSQL query and use detailed error messages from the server to debug the query.
- Attempt an HTTP Parameter Pollution attack to replace language-specific keywords, such as "where" within PHP [CAPEC-460].
|
| 4 |
Exploit |
[Exploit NoSQL Injection vulnerability] After refining and adding various logic to NoSQL queries, craft and execute the underlying NoSQL query that will be used to attack the target system. |
- Craft and Execute underlying NoSQL query
|
|
| Solutions | 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. |
| Related Weaknesses |
|
CWE ID
|
Description
|
| CWE-943 |
Improper Neutralization of Special Elements in Data Query Logic |
| CWE-1286 |
Improper Validation of Syntactic Correctness of Input |
|
| Related CAPECS |
|
CAPEC ID
|
Description
|
| CAPEC-248 |
An adversary looking to execute a command of their choosing, injects new items into an existing command thus modifying interpretation away from what was intended. Commands in this context are often standalone strings that are interpreted by a downstream component and cause specific responses. This type of attack is possible when untrusted values are used to build these command strings. Weaknesses in input validation or command construction can enable the attack and lead to successful exploitation. |
|