As a part of our current work on detecting NoSQL injection vulnerabilities with Invicti, we developed and added safety checks for MongoDB injection. This publish exhibits scan for MongoDB injection vulnerabilities with Invicti, analyze vulnerability experiences, and repair reported vulnerabilities.
What are MongoDB injection vulnerabilities?
MongoDB is by far the preferred NoSQL database and presently the fifth hottest database engine total (in line with the DB-Engines rating). Used alongside Specific, Angular, and Node.js, it’s the basis of the MEAN software program stack for constructing full-stack JavaScript net purposes. Technically, it’s a doc database sort that shops its paperwork in JSON format.
Just like conventional SQL injection, MongoDB injection assaults depend on unsanitized person enter and are carried out by getting into payloads that modify MongoDB queries. There are two important sorts of MongoDB injections: injecting MongoDB key phrases right into a weak PHP utility and injecting JavaScript into MongoDB queries. You could find an summary of MongoDB injection strategies in a earlier weblog publish on NoSQL injection, however here’s a fast recap.
MongoDB injection into PHP purposes
MongoDB injection in PHP purposes exploits the way in which that PHP converts associative arrays to inject MongoDB operators. As a fast instance with the $ne (not equals) operator, let’s say now we have a PHP utility that receives a parameter like title=check. PHP converts this to the array {"title":"check"}. If we will inject the parameter as title["$ne"]=check, PHP will convert the entire thing to {"title": {"$ne":check}}. When despatched to MongoDB as a question, this may now return all data whose title isn’t equal to check (due to the $ne operator).
JavaScript injection into MongoDB queries
MongoDB permits JavaScript expressions in some queries. When unsanitized person enter is handed on to the $the place question operator, attackers could possibly inject malicious JavaScript into database queries. Solely a restricted subset of JavaScript properties and capabilities will be injected, however that is fairly sufficient for a helpful assault – for instance, you’ll be able to entry the sleep() operate for time-based assaults.
Making ready the scanner to check for MongoDB injection vulnerabilities
As a result of MongoDB is the back-end database for thus many fashionable net purposes, NoSQL injection can now be simply as harmful as SQL injection. To assist organizations discover and remediate MongoDB injection vulnerabilities, now we have added absolutely automated safety checks for these vulnerabilities to Invicti merchandise. We’ll undergo the next steps to exhibit how one can simply establish and repair such safety defects:
- Arrange a weak utility for testing (NodeGoat)
- Run a scan with Invicti Customary
- Analyze the vulnerability report
- Observe down the vulnerability in utility code
- Remediate the vulnerability and comply with finest practices to keep away from related points sooner or later
Establishing the check surroundings
As our demo surroundings, we will use NodeGoat – a weak Node.js utility from OWASP that makes use of MongoDB. You could find extra details about the NodeGoat challenge on the OWASP web site. Establishing the appliance is a matter of issuing a couple of docker-compose instructions:
git clone https://github.com/OWASP/NodeGoat.git
docker-compose construct
docker-compose upIf all goes nicely, after executing these instructions, the NodeGoat utility needs to be accessible at http://[YOUR-IP-ADDRESS]:4000.
After accessing the appliance, we will create a brand new person on the primary web page:
The applying is now able to scan. To arrange and run the scan, we are going to use Invicti Customary. For detailed details about scanning, see our help web page on MongoDB injection checks.
MongoDB injection checks can be found in Invicti Customary variations later than 6.8.0.38168 and in Invicti Enterprise on-demand since October 2022.
Making a scan profile
For this straightforward check web site, all we have to do to create a scan profile is to set the goal URL and allow kind authentication:
Deciding on the scan coverage
The following step is to pick the MongoDB injection safety checks we wish to run. For blind MongoDB injections, choose MongoDB Injection (Blind) beneath the NoSQL Injection safety verify group:
To verify for error-based MongoDB injections, choose MongoDB Injection (Error-Based mostly) beneath the NoSQL Injection safety verify group:
Discovering and fixing MongoDB injection vulnerabilities
With the setup executed, now you simply hit the Scan button and study the outcomes. As a dynamic utility safety testing (DAST) answer, Invicti probes the appliance from the skin by sending requests that embody check assault payloads. The place potential, the scanner makes an attempt to soundly exploit vulnerabilities to show they’re actual. We’ll have a look at a MongoDB injection vulnerability report, discover the insecure utility code, remediate the problem, and retest to ensure it’s fastened.
Understanding scan outcomes
The NodeGoat utility has a deliberate MongoDB injection vulnerability beneath the allocations listing within the threshold parameter. Relying on which MongoDB injection safety verify is chosen, Invicti will report this vulnerability both as a blind MongoDB injection or an error-based MongoDB injection. For blind MongoDB injection, Invicti may even try to verify the vulnerability by extracting the model variety of the MongoDB occasion utilized by the appliance. When profitable, this can be reported within the Proof of Exploit part of the vulnerability report:
When detected utilizing checks for error-based MongoDB injections, the identical vulnerability is reported as follows:
Analyzing the vulnerability
Now that we all know now we have a vulnerability, we have to discover precisely the place it’s, how the assault payload will get via, and the way we will repair the problem. Within the anticipated utilization of the weak web page, the person enters an integer and the appliance shows the entire person’s inventory that’s presently valued above that threshold. Right here is an instance of output for the present person:
After scanning the appliance with Invicti, we now know that the Allocations web page is weak to NoSQL injections into the threshold parameter. We will affirm this manually by getting into this straightforward payload that ought to checklist asset allocations for all customers:
threshold=1'; return '1' == '1As you’ll be able to see under, the injection works and we will now see inventory knowledge for all utility customers within the output, not solely our check person:
Within the supply code of the NodeGoat utility, this vulnerability is launched within the allocations-dao.js file referenced by allocations.js within the app/routes folder. Let’s undergo the method of isolating this particular file based mostly on the vulnerability report.
We will begin by checking server.js within the root folder. This file is the place the NodeGoat utility begins and the place we will see which config file is used and which recordsdata are referenced. We will rapidly uncover that the ./app/routes folder is referenced as routes on line 16, so we will proceed checking app/routes to seek out the weak code:
Under, you’ll be able to see the construction of the ./app/routes folder:
The index.js file defines which URL is routed to which file. In line 5 of index.js under, we will see the allocations.js file is assigned to AllocationsHandler. This line is necessary and price checking as a result of, from the vulnerability experiences, we all know that the vulnerability is beneath http://[ipaddress]:4000/allocations/:id:.
Trying on the allocations.js file beneath ./app/routes, we will see that it takes userid and threshold as parameters after which calls the getByUserIdAndThreshold() technique from the file allocations-dao.js within the ./app/knowledge folder:
Lastly, within the allocations-dao.js file, we will seek for the getByUserIdAndThreshold() technique to see what it does. Instantly, you’ll be able to see that the MongoDB question makes use of the $the place operator, which is an prompt crimson flag (as defined earlier). Unsurprisingly, we will additionally see that the enter parameters are instantly used within the question with none validation or sanitization:
Now that we’ve discovered the basis reason behind the vulnerability, let’s see repair the problem and keep away from it sooner or later by following finest practices.
Easy methods to repair MongoDB injection vulnerabilities
In case you have a look at the vulnerability report delivered by Invicti, you will notice the next remediation steering for MongoDB injection vulnerabilities:
- Sanitize and strictly verify the kind of user-supplied enter.
- Keep away from utilizing
$the place,mapReduce, or$grouptogether with person enter. - If potential, set the
javascriptEnabledflag tofalsein mongod.conf. - Use the newest model of MongoDB.
Let’s undergo these suggestions to repair the vulnerability after which retest to see whether it is really fastened.
Sanitizing user-controlled inputs
All injection assaults are made potential by unsanitized inputs, so that is the place all remediation ought to begin. Because the NodeGoat utility was created by OWASP for academic functions, it already features a remediation technique. Trying on the allocations-dao.js file within the screenshot under, you’ll be able to see the repair advised within the remark (in blue):
The advised answer focuses on enter sanitization and validation by casting the threshold parameter to an integer after which checking whether it is between 0 and 99. See the documentation of the parseInt() operate to study extra about integer casting. To use this repair, merely uncomment it whereas commenting out the weak code. The code ought to now seem like this (be aware the uncommented part between traces 70 and 75):
Avoiding insecure MongoDB operators and instructions
Even with validated enter, you’ll be able to see that the appliance nonetheless makes use of the $the place operator within the question, which isn’t a safe follow when working with user-controlled inputs. To treatment this, we will write a greater and safer question. After a bit of search, we will recreate the question with out utilizing the $the place operator. In line 74 of the allocations-dao.js file under, you’ll be able to see the brand new question:
Disabling JavaScript in MongoDB configuration
If you already know your utility doesn’t use or want JavaScript in MongoDB queries, you need to disable JavaScript in mongod.conf utilizing MongoDB configuration choices. The javascriptEnabled possibility is true by default. When set to false, it disables all operations that carry out server-side JavaScript execution, reminiscent of $the place, mapReduce, $accumulator, and $operate. In a default set up, mongod.conf is positioned within the /and many others folder. To make the change, merely append javascriptEnabled: false to the safety part of the configuration file and restart the mongod service.
All the time utilizing the newest model
As a common safety finest follow, you need to all the time use the most recent safe variations of all software program wherever potential. Particularly for MongoDB, which had some critical safety points in early variations, utilizing the most recent model is necessary to forestall your utility from being weak to already printed vulnerabilities. See the MongoDB model historical past to find out how the database has advanced.
Retesting to ensure the vulnerability is fastened
After making use of all of the remediation steps, we will be fairly assured that the vulnerability is fastened – however testing is the one approach to make sure. To verify if we resolved the vulnerability, we will merely scan the appliance once more with Invicti Customary utilizing the identical coverage and profile. As you’ll be able to see, this time no outcomes are returned for MongoDB injection safety checks, so the vulnerability was not detected:
Conclusion
MongoDB databases are a vital a part of the trendy net, but automated safety testing instruments for NoSQL databases are nonetheless far much less mature than for relational databases. To deal with this, Invicti options can now detect when purposes are weak to MongoDB injections. Relying on the kind of safety verify, the scanner can mechanically affirm many such vulnerabilities by safely extracting model info from the MongoDB database.
Profitable NoSQL injection assaults will be simply as harmful as SQL injection, probably permitting attackers to learn, change, or delete knowledge and accumulate delicate details about the system. Figuring out the best safe growth practices for working with MongoDB is as necessary as commonly testing your purposes for safety points. Hopefully, this publish has proven that there are numerous methods to repair MongoDB injection vulnerabilities and keep away from them sooner or later – and that with the best instruments, you’ll be able to check and retest your purposes as typically as you want.
