Recently, we released a blog article about SQL Injections. If you are unfamiliar with the topic, I highly recommend you check it out. To answer the title question of the last article (spoiler alert): Yes, SQL injections are still a thing, and traditional testing methods such as Static Application Security Testing (SAST) and traditional Dynamic Application Security Testing (DAST) tools do not offer an adequate solution.
The problem with SAST is that the testing results do not always include the entire context, leading to a staggering number of false positives that take a lot of manual effort to be filtered out. Among other deficiencies, the main issue with traditional DAST is that it treats the application as a black box.
This means that the testing inputs do not generate any feedback, which would help construct requests that can trigger bugs hidden deep within the code structure. Additionally, DAST also requires manual assistance to guide inputs toward the numerous endpoints of an application. SQL injections provide us with a perfect example to showcase how whitebox-fuzzing approaches can outperform these traditional testing methods.
One approach to resolving these challenges is feedback-based fuzzing - a modern testing approach that effectively maximizes code coverage. This allows us to detect SQL injection vulnerabilities through bug detection mechanisms that are similar to IAST (Interactive Application Security Testing). It automatically identifies the endpoints of applications, so that no user interaction is needed for the test:
Automatic Endpoint Detection
For the most widely used web frameworks such as Spring Boot, we automatically analyze the application to extract the list of endpoints offered and the structure of the requests expected by each endpoint. This information is used to guide our fuzzer in order to generate and mutate requests that automatically reach all application endpoints with correctly-structured requests.
Deep Insights Through Feedback-Based Fuzzing
By instrumenting the code, we enable the fuzzer to receive feedback about code coverage. This way, the fuzzer can prioritize mutations that lead to inputs that maximize code coverage, enabling it to trigger bugs hidden deep within the code. Moreover, our instrumentation closely checks the operations performed by the code and reports interesting ones such as string comparisons back to the fuzzer.
Better Error Detection
Our instrumentation closely checks the application's interaction with the database. By dynamically intercepting all method invocations that interact with the database, we examine the SQL query that is about to be executed. If this query is malformed, an error is reported to the user.
Note that since we intercept all database-related method invocations, we are able to detect bugs even if the query is executed inside a try-catch statement that silently ignores any thrown exceptions. This way our platform collects information about executed queries and even checks queries that are not immediately triggered by a user request.
Since our software instruments Java Database Connectivity and Lightweight Directory Access Protocol databases, it knows which queries are being passed on to the database, allowing it to find instances in which users provoke invalid queries or vulnerabilities. This process, which can be categorized as a combination of feedback-based fuzzing and IAST, is entirely automated and does not require to be explicitly set up by the developer.
What Does This Mean for the Developer Workflow?
First, the whole testing process is fully automated and requires no manual assistance. When an SQL injection vulnerability is identified, CI Fuzz generates an extensive bug report that clearly shows the flaw in the code and the exact request that caused the error.
In order to raise security awareness about the detected vulnerabilities, the report clearly highlights why SQL injections are a security concern and gives developers insights on how to avoid, fix and secure SQL injections, with the aim to assist them to build secure software.
One of the main advantages of fuzzing is that the fuzzer generates a concrete input for each finding that causes the corresponding bug. Using CI Fuzz the user is able to debug the error so that he or she gets better insights into what caused the crash.
What’s to Come?
With the integration of OWASP’s ZAP into CI Fuzz the discussed methods already work for other OWASP top 10 bugs. Furthermore, we are working on advanced bug detectors for different types of bugs, like path injections, file I/O and more. If you are interested in how we can automatically detect and secure SQL injections within seconds, feel free to request a personalized demo with one of our security experts.
