Share this Post
SQL/NoSQL injections (differentiated in essence by the app-layer concerned, Although there are other important ins-and-outs) are a basic hacking trick and relatively easy to defend against but potentially devastating when not.
Hackers take advantage of insecurely coded web application software to insert malicious code into a company’s network and systems.
Along with the exposure element (such as Facebook’s exposure through RockYou’s compromised application element), a successful NoSQL injection grant attackers permission to update, insert, or delete data.
This allows long-standing insidious breaches, like changing balance/transactional data, causing repudiation problems, as well as major one-time hits, like the deletion of all system data.
This is the one of the most dangerous proverbial Trojan horses in today’s digital age, as it’s so easily overlooked. A NoSQL injection is an under-the-radar database breach that injects malicious code into a system.
Breaches usually exploit vulnerabilities in JavaScript and JSON code then sneak their way in, before deciding whether to blow the doors apart. Awareness on the matter is a must.
Let’s hash it out.
Table of Contents:
What Causes a NoSQL Injection Attack?
An application draws information from a NoSQL database as per normal but fails to fully validate the user input element before acting on the database query. The login is approved but not accurately justified.
We can better understand how a NoSQL injection exploits vulnerabilities via an example.
Before this, let’s go through a typical non-malicious authentication workflow:
A user inputs her credentials according to POST parameters (the username and password). These parameters append to a database query string — before its submission into the NoSQL database.
Because the credentials are valid, a correct record is transmitted to the web server along with the session cookie, which gets returned to the browser.
The user has now successfully logged in.
‘Authentication Bypass’
In this case, the attacker uses an interception proxy to submit input values that covertly alter the logic of the query. Rather than the proper username and password, a NoSQL comparison operator is passed through instead.
But because these parameters from the database will be compared to the empty string, the submission result will be an always true comparison/condition.
The attacker is then logged in as whoever the first user in that database is. For instance, as the administrator.
Implications of a Successful NoSQL Injection
- ☑️ Downtime from system availability.
- ☑️ Reputational/credibility damages.
- ☑️ Losses in revenue or customers.
NoSQL Injections vs Traditional SQL Injections (SQLi)
- ☑️ With NoSQL injections, code can be executed on the server after injection, in the web application’s language — opening the door to especially dangerous arbitrary code execution.
- ☑️ Successful NoSQL injections let attackers run commands not only in the database but also on the application layer, which can cause far deeper damage.
- ☑️ Examples of more dangerous attack vectors from NoSQL injections vs traditional SQL injections include denial of service (DDoS) attacks and breached admin user accounts that allow hackers full control of the server.
- ☑️ Fewer developers are aware of threat vectors possible in non-relational products. There are fewer precedents with which to model NoSQL injection methods. This generally increases the odds of vulnerable code being present in organization network systems.
The Bottom Line
As standard, today database owners need to carefully consider how to prevent a NoSQL injection attack — we’ll therefore close on that note:
- ☑️ Because JavaScript is a common SQLi entryway, all input should be JavaScript validated or escaped before it’s allowed to query the database.
- ☑️ Require green-list validation for user input — include Cookies, HTTP header elements, POST and GET parameters.
- ☑️ Follow the principle of least privilege for all database users.
- ☑️ Validate input parameters — during validation routines, constraint input to the permitted types.
- ☑️ Rather than raw queries, use a database ORM.
- ☑️ Replace implicit equality matching with explicit comparison operators — such as #eq in query expressions
Many of the new NoSQL products available (of which there are now more than 150) are still in their youth. Fast-moving developments are occurring in this space. It’s always the best policy to use the latest version.
For instance, MongoDB in the past was littered with serious injection vectors. The most important way to prevent NoSQL injection attacks is to sanitize user inputs in application code, and to avoid unsanitized paths.
This is particularly important regarding the creation of database queries. We recommend looking at the OWASP guide for testing for NoSQL injection to delve practically into testing your systems for large flaws.
