Menu

Are SQL injections still a thing?

published 2020-06-10, written by Jonathan Reimer

We often get asked by customers if SQL injections are still an issue in 2020. Even though this vulnerability is known for over 20 years, it still ranks number 1 in OWASP’s Top 10 for web vulnerabilities. Last year alone (2019), 410 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 smart 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.

exploits_of_a_mom

© www.xkcd.com

 

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 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 needs to be modelled 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 in order 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 catched 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.

 

Summary

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 mainly exist two security testing approaches: SAST and DAST. But both methods come with several limitations.
However, there is hope: Recent research has shown that fuzzing, in particular, can be a very effective method for detecting SQL injections. The fuzzing platform of Code Intelligence, CI Fuzz, finds injections with very high reliability and with virtually no false positives. In the next blogpost we will look at how this is done technically. If you don't want to miss this, you should subscribe to our newsletter.