Difference between revisions of "Testing for NoSQL injection"

Revision as of 14:59, 9 October 2012 (view source) Mmeucci (talk | contribs) (Created page with "{{Template:OWASP Testing Guide v4}} == Brief Summary == <br> ..here: we describe in "natural language" what we want to test. <br> == Description of the Issue == <br> ...her...")		Revision as of 15:29, 9 August 2013 (view source) Ben Walther (talk | contribs) m Newer edit →
Line 4:		Line 4:
	== Brief Summary ==		== Brief Summary ==
	<br>		<br>
−	..here: we describe in "natural language" what we want to test.	+	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>		<br>
	== Description of the Issue ==		== Description of the Issue ==
	<br>		<br>
−	...here: Short Description of the Issue: Topic and Explanation	+	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 <pre> < > & ; </pre> will not prevent JSON attacks, whose special characters include <pre> / { } : </pre>
		+
		+	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.
		+
		+	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>		<br>
	== Black Box testing and example ==		== Black Box testing and example ==

---

Revision as of 15:29, 9 August 2013

This article is part of the new OWASP Testing Guide v4.

Back to the OWASP Testing Guide v4 ToC:
   https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents
Back to the OWASP Testing Guide Project:
   https://www.owasp.org/index.php/OWASP_Testing_Project

Brief Summary

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[1] language , rather than in the declarative[2] SQL language, the potential impacts are greater than traditional SQL injection.

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

 < > & ; 

will not prevent JSON attacks, whose special characters include

 / { } : 

There are now over 150 NoSQL databases available[3] 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.

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.

Black Box testing and example

Testing for Topic X vulnerabilities:
...
Result Expected:
...

References

Whitepapers
...
Tools
...