Testing for NoSQL injection - Revision history

Jmanico: /* Example 1 */

2017-06-20T17:56:00Z

‎Example 1

Jmanico: fix from adriancohea@gmail.com

2017-06-20T17:54:45Z

fix from adriancohea@gmail.com

Cr0hn at 14:45, 22 September 2016

2016-09-22T14:45:33Z

Cr0hn: /* References */

2016-09-22T14:44:32Z

‎References

Nikolay Dimitrov Petkov at 11:16, 20 August 2014

2014-08-20T11:16:25Z

Andrew Muller: Align with Common Numbering

2014-08-05T14:27:18Z

Align with Common Numbering

Andrew Muller at 16:04, 31 July 2014

2014-07-31T16:04:16Z

Jane O'Connor: Final edit

2014-05-19T09:42:20Z

Final edit

Eoftedal: /* References */ typo

2013-08-19T13:26:53Z

‎References: typo

Ben Walther: References

2013-08-09T16:45:07Z

References

← Older revision		Revision as of 17:56, 20 June 2017
Line 50:		Line 50:


−	This input <code>"(function(){var date = new Date(); do{curDate = new Date();}while(curDate-date<10000); return Math.max();})()"</code> inserted into $userInput in the above example ~~code would result in~~ the ~~following JavaScript function being executed~~. This specific attack string would case the entire MongoDB instance to execute at 100% CPU usage for 10 second.	+	This input <code>"(function(){var date = new Date(); do{curDate = new Date();}while(curDate-date<10000); return Math.max();})()"</code> inserted into $userInput in the above example, this injection invokes an inline function which will trigger the denial of service first, and ultimately return a number.. This specific attack string would case the entire MongoDB instance to execute at 100% CPU usage for 10 second.
−
−	~~<code>function() { return obj.credits - obj.debits < 0;var date=new Date(); do{curDate = new Date();}while(curDate-date<10000); }</code>~~

	===Example 2===		===Example 2===

@@ Line 50: / Line 50: @@
-This input <code>0;var date=new Date(); do{curDate = new Date();}while(curDate-date<10000)</code> inserted into $userInput in the above example code would result in the following JavaScript function being executed. This specific attack string would case the entire MongoDB instance to execute at 100% CPU usage for 10 second.
+This input <code>"(function(){var date = new Date(); do{curDate = new Date();}while(curDate-date<10000); return Math.max();})()"</code> inserted into $userInput in the above example code would result in the following JavaScript function being executed. This specific attack string would case the entire MongoDB instance to execute at 100% CPU usage for 10 second.
 <code>function() { return obj.credits - obj.debits < 0;var date=new Date(); do{curDate = new Date();}while(curDate-date<10000); }</code>
 ===Example 2===

@@ Line 71: / Line 71: @@
 <br>
-== Injection payloads ==
 Injection payload wordlist with examples of NoSQL Injection for MongoDB - https://github.com/cr0hn/nosqlinjection_wordlists
 '''Whitepapers'''<br>
 Bryan Sullivan from Adobe: "Server-Side JavaScript Injection" - https://media.blackhat.com/bh-us-11/Sullivan/BH_US_11_Sullivan_Server_Side_WP.pdf

@@ Line 71: / Line 71: @@
 <br>
 == References ==
 '''Whitepapers'''<br>

← Older revision		Revision as of 11:16, 20 August 2014
Line 84:		Line 84:

	PHP Documentation: "MongoCollection::find" - http://php.net/manual/en/mongocollection.find.php		PHP Documentation: "MongoCollection::find" - http://php.net/manual/en/mongocollection.find.php
		+
		+	"Hacking NodeJS and MongoDB" - http://blog.websecurify.com/2014/08/hacking-nodejs-and-mongodb.html
		+
		+	"Attacking NodeJS and MongoDB" - http://blog.websecurify.com/2014/08/attacks-nodejs-and-mongodb-part-to.html

← Older revision		Revision as of 14:27, 5 August 2014
Line 68:		Line 68:


−	One way to potentially assign data to PHP variables is via HTTP Parameter Pollution (see: [[Testing_for_HTTP_Parameter_pollution_(~~OWASP~~-DV-004)]]). By creating a variable named <code>$where</code> via parameter pollution, one could trigger a MongoDB error indicating that the query is no longer valid. Any value of <code>$where</code> other than the string "$where" itself, should suffice to demonstrate vulnerability. An attacker would develop a full exploit by inserting the following: <code>"$where: function() { //arbitrary JavaScript here }"</code>	+	One way to potentially assign data to PHP variables is via HTTP Parameter Pollution (see: [[Testing_for_HTTP_Parameter_pollution_(OTG-INPVAL-004)]]). By creating a variable named <code>$where</code> via parameter pollution, one could trigger a MongoDB error indicating that the query is no longer valid. Any value of <code>$where</code> other than the string "$where" itself, should suffice to demonstrate vulnerability. An attacker would develop a full exploit by inserting the following: <code>"$where: function() { //arbitrary JavaScript here }"</code>

	<br>		<br>

@@ Line 2: / Line 2: @@
-== Brief Summary ==
+== Summary ==
 <br>
 NoSQL databases provide looser consistency restrictions than traditional SQL databases. By requiring fewer relational constraints and consistency checks, NoSQL databases often offer performance and scaling benefits. Yet these databases are still potentially vulnerable to injection attacks, even if they aren't using the traditional SQL syntax. Because these NoSQL injection attacks may execute within a procedural[http://en.wikipedia.org/wiki/Procedural_programming] language , rather than in the declarative[http://en.wikipedia.org/wiki/Declarative_programming] SQL language, the potential impacts are greater than traditional SQL injection.
 <br>
-== Description of the Issue ==
 NoSQL database calls are written in the application's programming language, a custom API call, or formatted according to a common convention (such as XML, JSON, LINQ, etc). Malicious input targeting those specifications may not trigger the primarily application sanitization checks. For example, filtering out common HTML special characters such as <code> < > & ; </code> will not prevent attacks against a JSON API, where special characters include <code> / { } : </code>.
@@ Line 21: / Line 20: @@
 <br>
-== Black Box testing and example ==
+== How to Test ==
 '''Testing for NoSQL injection vulnerabilities in MongoDB:''' <br>
 The MongoDB API expects BSON (Binary JSON) calls, and includes a secure BSON query assembly tool. However, according to MongoDB documentation - unserialized JSON and JavaScript expressions are permitted in several alternative query parameters.[http://docs.mongodb.org/manual/faq/developers/#javascript] The most commonly used API call allowing arbitrary JavaScript input is the $where operator.

@@ Line 6: / Line 6: @@
 NoSQL databases provide looser consistency restrictions than traditional SQL databases. By requiring fewer relational constraints and consistency checks, NoSQL databases often offer performance and scaling benefits. Yet these databases are still potentially vulnerable to injection attacks, even if they aren't using the traditional SQL syntax. Because these NoSQL injection attacks may execute within a procedural[http://en.wikipedia.org/wiki/Procedural_programming] language , rather than in the declarative[http://en.wikipedia.org/wiki/Declarative_programming] SQL language, the potential impacts are greater than traditional SQL injection.
 <br>
 == Description of the Issue ==
 <br>
 NoSQL database calls are written in the application's programming language, a custom API call, or formatted according to a common convention (such as XML, JSON, LINQ, etc). Malicious input targeting those specifications may not trigger the primarily application sanitization checks. For example, filtering out common HTML special characters such as <code> < > & ; </code> will not prevent attacks against a JSON API, where special characters include <code> / { } : </code>.
 There are now over 150 NoSQL databases available[http://nosql-database.org/] for use within an application, providing APIs in a variety of languages and relationship models. Each offers different features and restrictions. Because there is not a common language between them, example injection code will not apply across all NoSQL databases. For this reason, anyone testing for NoSQL injection attacks will need to familiarize themselves with the syntax, data model, and underlying programming language in order to craft specific tests.
 NoSQL injection attacks may execute in different areas of an application than traditional SQL injection. Where SQL injection would execute within the database engine, NoSQL variants may execute during within the application layer or the database layer, depending on the NoSQL API used and data model. Typically NoSQL injection attacks will execute where the attack string is parsed, evaluated, or concatenated into a NoSQL API call.
-At the time of writing MongoDB is the most widely used NoSQL database, and so all examples will feature MongoDB APIs.
+Additional timing attacks may be relevant to the lack of concurrency checks within a NoSQL database. These are not covered under injection testing. At the time of writing MongoDB is the most widely used NoSQL database, and so all examples will feature MongoDB APIs.
 <br>
 == Black Box testing and example ==
 '''Testing for NoSQL injection vulnerabilities in MongoDB:''' <br>
 The MongoDB API expects BSON (Binary JSON) calls, and includes a secure BSON query assembly tool. However, according to MongoDB documentation - unserialized JSON and JavaScript expressions are permitted in several alternative query parameters.[http://docs.mongodb.org/manual/faq/developers/#javascript] The most commonly used API call allowing arbitrary JavaScript input is the $where operator.
 The MongoDB $where operator typically is used as a simple filter or check, as it is within SQL.
 <code> db.myCollection.find( { $where: "this.credits == this.debits" } ); </code>
 Optionally JavaScript is also evaluated to allow more advanced conditions.
 <code> db.myCollection.find( { $where: function() { return obj.credits - obj.debits < 0; } } ); </code>
 ===Example 1===
@@ Line 35: / Line 41: @@
 <code>db.myCollection.find( { active: true, $where: function() { return obj.credits - obj.debits < $userInput; } } );;</code>
 As with testing other types of injection, one does not need to fully exploit the vulnerability to demonstrate a problem. By injecting special characters relevant to the target API language, and observing the results, a tester can determine if the application correctly sanitized the input. For example within MongoDB, if a string containing any of the following special characters were passed unsanitized, it would trigger a database error.
 <code>' " \ ; { }</code>
 With normal SQL injection, a similar vulnerability would allow an attacker to execute arbitrary SQL commands - exposing or manipulating data at will. However, because JavaScript is a fully featured language, not only does this allow an attacker to manipulate data, but also to run arbitrary code. For example, instead of just causing an error when testing, a full exploit would use the special characters to craft valid JavaScript.
 This input <code>0;var date=new Date(); do{curDate = new Date();}while(curDate-date<10000)</code> inserted into $userInput in the above example code would result in the following JavaScript function being executed. This specific attack string would case the entire MongoDB instance to execute at 100% CPU usage for 10 second.
 <code>function() { return obj.credits - obj.debits < 0;var date=new Date(); do{curDate = new Date();}while(curDate-date<10000); }</code>
 ===Example 2===
 Even if the input used within queries is completely sanitized or parameterized, there is an alternate path in which one might trigger NoSQL injection. Many NoSQL instances have their own reserved variable names, independent of the application programming language.
 For example within MongoDB, the <code>$where</code> syntax itself is a reserved query operator. It needs to be passed into the query exactly as shown; any alteration would cause a database error. However, because <code>$where</code> is also a valid PHP variable name, it may be possible for an attacker to insert code into the query by creating a PHP variable named <code>$where</code>. The PHP MongoDB documentation explicitly warns developers: <pre>Please make sure that for all special query operators (starting with $) you use single quotes so that PHP doesn't try to replace "$exists" with the value of the variable $exists.</pre>
 Even if a query depended on no user input, such as the following example, an attacker could exploit MongoDB by replacing the operator with malicious data.
 <code> db.myCollection.find( { $where: function() { return obj.credits - obj.debits < 0; } } ); </code>
 One way to potentially assign data to PHP variables is via HTTP Parameter Pollution (see: [[Testing_for_HTTP_Parameter_pollution_(OWASP-DV-004)]]). By creating a variable named <code>$where</code> via parameter pollution, one could trigger a MongoDB error indicating that the query is no longer valid. Any value of <code>$where</code> other than the string "$where" itself, should suffice to demonstrate vulnerability. An attacker would develop a full exploit by inserting the following: <code>"$where: function() { //arbitrary JavaScript here }"</code>

@@ Line 65: / Line 65: @@
 Bryan Sullivan from Adobe: "NoSQL, But Even Less Security" - http://blogs.adobe.com/asset/files/2011/04/NoSQL-But-Even-Less-Security.pdf
-Erlend from Brekk Consulting: "[Security] NOSQL-injection" - http://erlend.oftedal.no/blog/?blogid=110
+Erlend from Bekk Consulting: "[Security] NOSQL-injection" - http://erlend.oftedal.no/blog/?blogid=110
 Felipe Aragon from Syhunt: "NoSQL/SSJS Injection" - http://www.syhunt.com/?n=Articles.NoSQLInjection