Intro

In many ways, the concept of nosql injection is very similar to that of the conventional sql injection. There are time-based (using sleep to test logic), boolean based (judging on output state) and error based (viewing the error message that comes back).

Where does nosql occur

By convention, sql is a layer 5 language (i.e session layer) in the OSI model. However, sqli actually takes place on Layer 7 (i.e the application layer). nosql injection follows a similar concept. You are most likely able to identify an entry point of nosqli on the application layer, e.g web application. Note that nosql doesn’t really follow the conventional common query language, instead, the queries are written in programming languages such as python, php, js, java. Therefore, not only a nosqli can be executed in the database, but also it can be executed in the application.

A typical example of nosqli is mongodb, where according to its documentation: https://www.mongodb.com/docs/manual/faq/fundamentals/#how-does-mongodb-address-sql-or-query-injection, mongodb allows server to run queries within the $where and mapReduce operations. Therefore, mongodb has been well-known for nosqli. Once it occurs, the attack can not only extract data from the database, but also execute code in the context of the application.

How to identify a nosql injection entry point

Similar to the conventional sqli injection, there are certain key characters we can use to identify (with a reasonable level of confidence) if a potential injection entry point exists, such as using ', ", ;, --, @ etc. It is possible to use a similar approach to test if an applicatino might be nosql injectable, for example using the following characters:

'"\/$[].>

However, one needs to also take into account of the format of data presentation. Conventionally, if we are talking about a web application, the data is likely to be presented in the following format:

Content-Type: application/x-www-form-urlencoded

It is desirable for one to also test what other formats the application server supports, such as

Content-Type: application/json

Afterwards, one can attempt to try a few injection phrases to figure out if the target is nosql injectable. The hacktricks site provides some good examples of this for authentication bypass:

#in URL
username[$ne]=toto&password[$ne]=toto
username[$regex]=.*&password[$regex]=.*
username[$exists]=true&password[$exists]=true

#in JSON
{"username": {"$ne": null}, "password": {"$ne": null} }
{"username": {"$ne": "foo"}, "password": {"$ne": "bar"} }
{"username": {"$gt": undefined}, "password": {"$gt": undefined} }

It is also advisable to use an automated tool to test the target, such as: https://github.com/Charlie-belmer/nosqli

Remediation

nosql is a fairly new concept comparing to the conventional database concept. Therefore, keeping the database up-to-date is always a default starting point.

Developers have a tendency of learning and using new technologies. However, it also implies time-spent in learning new technologies, and sometime it’s only learnt to the point of completing a project rather than learning to its depth. However, due to how rapidly the software industry evolves, we are coming to a unable-to-catch-up point of new-tech and complexity.

As always, user-input cannot be directly trusted, input validation and escaping are a default.