User input is a vital part of interacting with your favorite brands and websites. Without this feature, anything from eCommerce to Maps would be an impossibility, making user input a key cornerstone of the internet’s widespread adoption. However, if users can add to a database, there needs to be a mechanism to prevent access to the database itself. Unfortunately, a foundational piece of database architecture developed in 1998 paved the way for a threat that surpasses even its own programming language. This is how NoSQL injection continues to cost millions per year.
The threat of code injection
Code injection describes the process of executing malicious code by means of a vulnerable application or webpage. The app or page with this vulnerability provides the attacker with initial access to an organization’s environment. SQL injection, therefore, describes an attack that utilizes a specific weakness within the Structured Query Language (SQL). This language is used to primarily link a user interface with its underlying database – meaning, when an attacker sinks their claws into this weakness, they gain access to the database itself.
Cases of SQL injection were first documented in 1998 by Jeff Forristal in the popular hacking zine Phrack. Following a code of full disclosure, Forristal notified Microsoft that this vulnerability impacted their hugely popular SQL Server product. Microsoft’s response was shocking: they all but dismissed Forristal, stating that it’s not a problem at all. Following this official communication, large-scale SQL injection attacks started to crop up with increasing frequency. One of the first publicized was the 2007 7-Eleven attack.
Here, Russian threat actors used SQL to pry open the convenience store’s customer debit card database. These compromised cards were then used to withdraw cash in Russia; the attackers are estimated to have stolen upwards of $2 million. The same perpetrators then went on to attack Heartland Systems, one of the largest banking providers at the time, with precisely the same approach. 100 million cards and over 650 financial services companies were compromised, at a total cost of hundreds of millions of dollars.
Following this, UK mobile providers TalkTalk found themselves on the receiving end of a SQLi breach in 2015. After acquiring Italian telecoms firm Tescali in 2009, the British company had completely neglected to upgrade any of the old database architecture, resulting in severe security vulnerabilities. In the 2015 attack, over 150,000 private data records were stolen – this included over 15,000 bank details, in the form of account numbers and sort codes. The estimated cost to TalkTalk was over £30 million.
However, database management and handling has come on leaps and bounds in the 20 years since SQL’s introduction. Other solutions have adapted and evolved, offering far more scalable and developer-friendly solutions. Unfortunately for modern security professionals, SQL set the original foundation that even modern databases follow.
SQL: The Ancestor of NoSQL
When you visit a website, part of the data is parsed back at the server. For example, when you pop over to a blog and choose an article, the URL may end in ‘id=1’. This gives you blog post number 1, as each number corresponds to a different post. With SQLi, an attacker changes that identifying feature in the URL, in order to force the database to return a piece of data.
The format of NoSQL coding languages all follow the same rough structure that SQL introduced, as they share a similar function. Furthermore, thanks to the focus that NoSQL places on flexibility, NoSQL attacks can cause even more damage than conventional SQL functions, as attackers are presented with a broader range of approaches.
Take MongoDB, a very common modern database. Alongside the traditional SQL attack approach, NoSQL languages include a host of other options: MongoDB’s $where component is one such example. This is a query operator that remains unchanged throughout – changing this construct can completely break chunks of code. That said, MongoDB will also accept $where as a name that is valid for a variable. This means that, if an attacker wants to inject malicious functions into this vulnerable code, then they simply need to create a PHP variable called $where. Though MongoDB’s documentation includes clear warnings regarding this vulnerability, there are a number of factors that result in developers continuing to build insecure applications. From tight deadlines to developer ignorance, the NoSQL threat has continued to top OWASP’s list of top 10 cybersecurity threats year after year.
NoSQL Injection Prevention
The most bulletproof form of NoSQL injection prevention is to avoid using raw user input in application code, particularly around database queries. Beyond this rule, development teams would be wise to invest in training, ensuring that developers understand how to implement security best practices, and support this by giving developers enough time to patch security flaws before the product is shipped.
However, if you’re reliant on third-party applications, your options are more limited. Many NoSQL options are in development, making it critical to use the most recent version and upgrade periodically. However, the reality is that preventing NoSQL attacks requires a solid and well-adapted fleet of cybersecurity solutions. One of the most effective anti-injection tools is a Web Application Firewall (WAF), which sits at the perimeter between an application and the public-facing internet. Every query that the user makes – and any data the app returns – is now passed through this solution, which compares the input with a pre-set list of allowable functions. By forcing input fields to adhere to these sets of rules, attackers are unable to pry open your databases, or add their own malicious code into vital applications.
