In this first part of a two-part post series, we’ll reconstruct a NoSQL injection and cover the basics of mitigating it. In the second part, we’ll look at Server-Side JavaScript and Blind Injection attacks against NoSQL databases.

If you’re not validating or escaping user-manipulated input properly, you may find malicious parties executing dynamic queries against your SQL and NoSQL databases.

The attack vector, however, differs due to differences between these two types of databases. For example, the following won’t affect NoSQL databases (even if the malicious user input hasn’t been sanitized/escaped):

db.users.findOne({username: username, password: password});

Similarly, if the attacker suspects that “admin” is valid for the SQL database, they could use the following for a username field:

admin’ — 

These examples are high-level illustrations of how an attacker can try to alter the original SQL query. But, because the query language structure of NoSQL databases (such as MongoDB) is different, these queries don’t have the same negative effects as they would with a SQL database.

The Anatomy of a NoSQL Injection

With a typical application, you can expect to receive a username/password combination either using an HTML’s form handler or via an AJAX call where the request sends the information as JSON. For an ExpressJS web application, you’ll need the following middleware for the latter type of requests:

#nosql #javascript #shiftleft #application-security #security