SQL Injections (SQLi) are one of the most dangerous and common vulnerabilities in existence. In the past few years, however, NoSQL databases have risen in popularity as back-end databases for web applications and distributed cloud platforms owing to ease of use and scalability. Given that SQL queries are not performed in these NoSQL (non-SQL/ not only SQL) databases, does that mean non-SQL databases are not vulnerable to injection attacks? Unfortunately, No.
So, how to prevent NoSQL? Let us begin with an overview of NoSQL injection.
NoSQL is a broad term used to refer to non-relational databases/ data storage systems that do not use SQL query language. Some examples are MongoDB, Cassandra DB, CouchDB, and Riak. Of these, MongoDB is the most popular database.
While SQL databases are stored in tables, a multiplicity of data models that are better suited to the purposes/ contexts are used in non-SQL data storage systems. For instance, objects, documents, graphs, key-values, column families, and many more. Given that dynamic schema definitions are supported, new fields and data can be added/ modified with ease as per the agile development cycles, unlike SQL databases.
Cyber-attacks where malicious payload is injected into non-SQL databases, such as MongoDB, are called NoSQL Injection.
SQL Injection is caused when queries (especially from users) are un-sanitized, allowing the database engine to be modified by the attacker to include malicious inputs that execute commands in the database. However, SQLi cannot be performed on non-SQL databases since they do not have a specific language. They have product-specific grammar and query syntaxes, which are written in the application language itself.
The result – Not only can the NoSQL databases be breached by attackers, but malicious code/ unvalidated inputs can be executed in the application itself. So, DDoS attacks can be orchestrated, or servers were taken over or confidential user information compromised by attackers by exploiting non-SQL injection vulnerabilities.
In a typical NoSQL architecture, data access is done via drivers. Libraries in multiple languages for the DB client are made available through drivers – access protocol. Considering the drivers may not be vulnerable, but unsafe APIs may be present in them, which if implemented insecurely by developers can open possibilities for arbitrary code execution on the database and the application itself.
Let us consider the example of MongoDB.
For example:
The code snippet below, which uses $where query operator retrieves the record with name ‘Rafael Silver’.
Here the attacker can insert unsanitized user input through the variable $userData
If the injection were successful, he might then inject the string, ‘a’; sleep (5000) into the variable $userData, which would pass the server for 5 seconds – this is enough for the attacker to execute what he needs.
The risk of insecure coding is exacerbated because these databases are still new and novel for several developers who are only familiar with SQL and relational databases. The security guidelines and manuals for NoSQL databases must be read carefully and thoroughly. The developers must understand the language being used to ensure that vulnerable constructs are avoided.
Developers must choose the latest available versions of these rapidly developing and young databases. For instance, the initial versions of the popular MongoDB were insecure by design on several levels, leading to lethal injection attacks while the latest versions have been strengthened on the security front.
As with SQL Injections, un-sanitized user inputs must be avoided in application code while building database queries. All user inputs must be validated to ensure that malicious values are not used.
While in-built features are available in non-SQL databases like MongoDB to avoid JavaScript in database queries, if JavaScript is unavoidable, input validation is a must.
As a rule, in web application security, the principle of least privilege must be followed. This way, the reach of attackers, in case of successful attacks, can be limited.
Conclusion
NoSQL ≠ No Injection attacks. Non-SQL databases are vulnerable to dangerous and damaging attacks, which must be proactively prevented. Even with the best-efforts during development and deployment, vulnerabilities may remain in the application, causing the risk of non-SQL injections to increase. Onboarding a comprehensive, intelligent, and managed security solution like AppTrana will be valuable in pre-empting attacks and strengthening application security.
Stay tuned for more relevant and interesting security articles. Follow Indusface on Facebook, Twitter, and LinkedIn.
This post was last modified on December 8, 2023 12:16
A Managed WAF is a comprehensive cybersecurity service offered by specialized providers to oversee, optimize,… Read More
Explore crucial tactics like Asset Inventory, Patch Management, Access Control & Authentication, and additional best… Read More
Delve into the data privacy questions including consent protocols, data minimization strategies, user rights management,… Read More