Introduction
I’m sure most of you have heard of SQL injection but what about NoSQL injection? SQL injection is in the OWASP top 10 and has been around for decades impacting databases such as mysql. NoSQL injection is similar to SQL injection except it targets different technologies such as MongoDB, Redis, Memcache and couchDB.
MongoDB
To really understand NoSQL injection you have to understand the technologies it impacts. MongoDB is one of the databases where noSQL injection tends to pop up. MongoDB is a document-oriented NoSQL database used for high volume data storage. Instead of using tables and rows as in the traditional relational databases such as MySql, MongoDB makes use of collections and documents. Collections contain sets of documents which are the equivalent of tables in MySql. Documents consist of key-value pairs(similar to JSON) which are the basic unit of data in MongoDB.
The main benefit of using a NoSql database instead of a relational database is that with NoSql you can store unstructured data. This means you don’t have to worry about creating columns as you do with relational databases, you just give it data and it stores it. Also the queries are a little different, there isn’t a query language , you typically just use key value stores such as json to perform queries.
MongoDB is really easy to use and developers like this. Queries are easier to form and you don’t have to worry about linking tables and creating columns as you do with MySql.
As shown above MongoDB has 24.6% of the market share. This essentially means 1 out of 4 sites you test will be running Mongodb. In reality I typically see a combination of relational databases and NoSql databases. Either way as an attacker it’s important to know that this is a popular database and your SQL payloads wont work here.
Suppose a developer wants to revive a customers record they might use the following request:
As you can see from the code above we are querying the “users” collection and returning the row which contains the specified user and password. We will come back to this query later but now you need to understand MongoDbs operators.
As shown in the image above an operator allows us to make calculations. For instance the following query tells the compiler to only return data where the username field is not equal to a blank string:
- db.users.find({“username”: { $ne: “”}})
That was a very brief overview on MongoDB and should give you just enough to understand NoSql injections. However, there is a bunch of stuff I didn’t cover but this is a hacking blog not a database blog.
NoSql Injection
As shown in the example request below we are trying to login to the application with the user ‘admin’ and the password ‘p@ssw0rd’:
Let’s suppose on the backend it eventually gets sent to the follow piece of code described earlier:
In this scenario our username and password would be placed into the query. This may look safe but its not, an attacker could enter unexpected queries. Concatenating strings together is always a bad idea, just like with sql injection an attacker could insert malicious commands which will be executed by the database. For example if we changed our password to {$ne: “”} it would log us in. Remember “$ne”is the not equal operator, since it is matching on a password not equal to a blank string it will result in true.
The big thing to note here is that there aren’t any select queries thats for relational databases and SQL injection. If you want to find this bug you need to understand what technology stack your target is running so you can adjust your payloads accordingly.
Conclusion
NoSQL injection isn’t a new bug, it’s just not as popular as traditional sql injection. However, I have noticed an uptick in the number of developers switching from relational databases to NoSql databases. As NoSql databases grow in popularity this type of bug will appear more and more so it’s important to know how to find and exploit it. As you saw, it’s not that hard to exploit if you know what you’re looking for. Instead of spraying Sql injection payloads everywhere, take a second to figure out what database the backend is using, nowadays there is a decent chance of it being a NoSql database.