SBN

What is NoSQL injection?

Introduction to injection

Injection attacks are considered some of the most dangerous types of vulnerabilities in existence. According to the OWASP Top Ten List of web application vulnerabilities, injection is the most common and dangerous type. On the 2019 CWE Top 25 Most Dangerous Software Errors list, poor input sanitization (which enables injection attacks) took the number three spot.

Injection vulnerabilities exist in a variety of different contexts, but they all boil down to the same issue. Several different languages, whether SQL, LDAP or the Linux shell, mix code and data together in commands.

In many cases, the data is supplied by untrusted users. While the language typically differentiates code from data, this differentiation usually amounts to a pair of single or double quotes. If a user can close a set of quotes (e.g., by including one in their input), they can get part of their data interpreted as code and executed by the program.

This is why poor input sanitization is the primary enabler of injection attacks. If certain dangerous characters (like quotes) are disallowed or escaped in user-supplied input, they can’t be used to close the quotes that delineate the user’s input as data. However, many developers fail to properly sanitize user input, leaving their applications open to attack.

NoSQL injection attacks

SQL injection is a well-known vulnerability. SQL is designed to enable queries to be performed against a database, extracting data based upon logical operators. Since these queries often include user-provided input, they can be vulnerable to attack if input sanitization is not properly performed.

NoSQL databases do not use SQL to perform queries. However, this does not make them invulnerable to injection attacks. Since queries still include user-provided data, a failure to properly sanitize this user input can still be dangerous.

Introduction to NoSQL

(Read more...)

*** This is a Security Bloggers Network syndicated blog from Infosec Resources authored by Howard Poston. Read the original post at: http://feedproxy.google.com/~r/infosecResources/~3/PlZDorl-34E/