We often get asked by customers if SQL injections are still a thing. Even though this vulnerability is known for over 20 years, injections still rank number 3 in the OWASP’s Top 10 for web vulnerabilities. In 2022, 1162 vulnerabilities with the type “SQL injections” have been accepted as a CVE. So the answer is: Yes, SQL injections are still a thing. This blog post is intended to give an overview of the existing challenges and solutions of SQL injections, and also to highlight the new possibilities of fuzzing in this context. But let’s start from scratch:
What Is an SQL Injection?
An SQL injection is an attack where the user can insert SQL statements into the input data provided to an application. If this input is not properly sanitized, the application executes attacker-controlled statements on the database, enabling the attacker to steal sensitive information or change the data. The main reason behind injection attacks is the lack of input validation that can lead to arbitrary commands being run on the database.
Why Are SQL Injections Still a Thing?
In today's age, it’s fascinating how frequently even large organizations fail to prevent SQL injections, even though the market is full of commercial and open-source tools claiming to eliminate them. Nevertheless, we have identified the following reasons for the high volume of SQL injections:
- Developers often lack certain security awareness.
- There are hardly any automated and efficient testing methods that allow a precise detection of injections (e.g. without false positives).
- Database access libraries that should provide a safe way for accessing DBs, e.g. by encouraging the usage of prepared statements, can often still be misused while giving the developer a false sense of security.
- Almost every web application out there uses some form of database in the backend. The quantity of SQL databases alone offers a certain surface for attack.
How to Detect SQL Injections
But let’s take a closer look at the existing methods for the prevention of SQL injections. In simple terms, there are two approaches (which both have their limitations):
Static Analysis for SQL Injections
SAST, or Static Application Security Testing, analyses the code without actually executing it. These techniques mainly rely on data flow analysis to track how to input data are handled and used by the program. Based on that, taint analysis is performed to check whether the data supplied by the user can reach critical operations of the application without the necessary validation.
For this to work reasonably well, the built-in programming language and framework features need to be modeled precisely. The lack of precision and the fundamental challenge of statically building a precise model of the program leads to imprecise results and a high rate of false positives.
To use these tools effectively, a difficult and time-consuming manual analysis by the developers or security experts must be performed to filter out the false positives and find the actual bugs from the generated reports, so the practical use of static analysis tools is limited.
Dynamic Testing for SQL Injections
DAST, or Dynamic Application Security Testing, is performed by actually executing the application and analyzing it during runtime. Dynamic vulnerability scanners such as OWASP ZAP or SQLmap try to attack the application by sending requests to the various endpoints of a web app and monitoring the responses for hints for potential vulnerabilities.
These hints include things such as specific MySQL error messages. Current dynamic analysis tools have several limitations: First, they treat the application as a black box, so they do not have any insights from the execution to construct requests that can trigger deep bugs in the code. Second, they need external assistance to identify how to reach the various endpoints offered by the application and the structure of the requests that are accepted by each endpoint.
Moreover, they fail to detect vulnerabilities that do not result in corresponding error messages, e.g., if the error is caught by the code an error message is silently discarded. Also, it is hard for those tools to find certain types of SQL injections that do not immediately display results back to the user (so-called "blind SQLi") or "second-order SQLi" where malicious user input is stored on the server and only later processing leads to an SQL injection.
Preventing SQL Injections
Regarding the opening questions: Yes, SQL injections are still one of the most exploited security vulnerabilities and, therefore, still a thing. In order to prevent SQL injections, there are two security testing approaches SAST and DAST. Both methods come with several limitations.
However, there is hope: Recent research has shown that fuzzing can be a particularly effective method for detecting SQL injections. Code Intelligence's platform finds injections with very high reliability and virtually no false positives. You can start using CI Fuzz today for free to find SQL injections in your applications.
