Originally published on March 5, 2019
If you’re an application developer, Database administrator (DBA), or any flavor of technologist, code injection should be on your radar.
You have a secure cloud environment. You have database access locked down. But what about your application code? Although it’s considered more secure, the No in NoSQLi does not mean it’s un-injectable! NoSQL can be as susceptible to code injection as any other database code. Not guarding against code injection is like having a security system in place for your doors and leaving a back window open.
What is code injection?
Code injection is simply unvalidated data being injected (or added) into a vulnerable program where it executes in the form of application code, often to disastrous results.
SQLi is one of the most common types of injection and, at over a decade old, is still going strong. Injection issues aren’t particular only to database languages. Beyond SQL and NoSQL, an injection can occur in XPath®, XML Parsers, SMTP headers, and other contexts. As far as severity goes, code injection is akin to remote code execution (RCE)—the Game Over screen of penetration testing.
It’s vital to detect and prevent NoSQLi in your applications. Allowing an unmitigated injection vector can threaten the safety of your user base, representing a possible business-ending loss of trust. Fortunately, after you understand the mechanics, you can take concrete steps to detect and prevent NoSQLi vulnerabilities in your services.
Simple NoSQLi examples
Typically, MongoDB® ingests Binary JSON (BSON) data constructed by using a secure BSON query construction tool. But
in certain cases, MongoDB can also accept unserialized JSON and Javascript (JS) expressions, such as the $where operator.
As with SQL, the $where operator is prone to a potential injection in NoSQL. However, unlike in SQL, the NoSQL $where
expresses its conditional in JS. This means it can use the full expressive power of JS to craft possible
injection queries instead of being limited to what SQL provides.
Going through lists of MongoDB injection strings in public repositories such as this one illustrates some of the common injection strategies, which parallel similar vulnerabilities in SQL and other languages.
For example, some use the classic 1 == 1 expression to force a query to return a true value in an attempt to read
hidden (or admin-level) resources and privileges:
$Where: '1 == 1'
Other snippets emulate a blind injection strategy by using the
sleep() function to slow the DB down and create a side-effect that—in conjunction with craftily-designed filters—can
enumerate sensitive information:
';sleep(5000); ';it=new%20Date();do{pt=new%20Date();}while(pt-it<5000);
And then of course there’s plain old data exfiltration, where the injected query is trying to match and retrieve critical information directly.
' && this.password.match(/.*/)//+%00
After the first example, the remaining two don’t use the $where operator. You don’t need a handy JS-flavored
expression as a foothold to attack a NoSQL DB.
Preventing NoSQLi
There are several general strategies to pursue when trying to build a NoSQLi-resistant application architecture. It’s no surprise that they conform with general anti-injection advice.
MongoDB / NoSQLi is no exception
Some people see code injection as being SQL-specific and underestimate the validity of injection principles applied to other contexts. Hopefully, this post convinces you that NoSQLi is real. This is well-documented in posts similar to MongoDB will not prevent NoSQL injections in your Node.js app
Do not trust unvalidated user data
For security reasons, you shouldn’t trust users!
This might come across as being cliche in security, but expect every input to be probed with malicious intent. Our $where
example earlier clearly illustrates why we can’t do something along the lines of $where: unvalidated_input—we might
think we’re exposing the filter to the user at this point (bad enough!). The fact that users are introducing unvalidated data
into the larger query is far from being a best practice.
Be wary of language or integration specifics
Even though NoSQLi isn’t special when it comes to being immune to injection (and suffers from many of the same types of attacks),
that doesn’t mean there aren’t also strategies unique to NoSQLi—or even to the languages or components built on top of a
NoSQL DB. A prominent example is that since $where is formatted in a way that passes as a PHP variable, a NoSQL DB built on
top of a PHP application has to account for this and the possible scenario of a malicious string injection stored in $where.
Conclusion
Again, the No in NoSQLi does not mean un-injectable! NoSQL, similar to SQL, SMTP headers, XML, and other contexts, is just as susceptible to code injection and the general treating-things-as-application-code-that-aren’t-application-code pitfalls that plague so many other technologies.
Hopefully, this post has provided you with a greater understanding of NoSQLi and what it means to your business. Now, you can steer your code to processes that make it less prevalent, less widespread, and less impactful. If you need some MongoDB management advice to make sure your app and hosting environment is secure, Rackspace ObjectRocket has experienced DBAs who can help.
Learn more about Rackspace DBA Services.
Use the Feedback tab to make any comments or ask questions. You can also click Sales Chat to chat now and start the conversation.