Steps to Detect SQL Injection Vulnerabilities

Introduction

In our previous blog post, we discussed the different types of SQL injection vulnerabilities. If you missed it, you can check it out here. Understanding these types is crucial as we delve into how to find SQL injection vulnerabilities in applications. In this post, we'll cover a step-by-step methodology for identifying these weaknesses.

How to Find SQL Injection Vulnerabilities

Imagine you've been tasked with testing an application for SQL injection vulnerabilities. Here's a comprehensive guide to help you identify potential weaknesses.

Note: The approach to finding SQL injection vulnerabilities can vary from person to person and is usually honed through experience. Use the methodology provided as a guide, but feel free to adapt it as you gain more experience in penetration testing web applications.

Categories of Testing

We've categorized the testing process into two perspectives: black box testing and white box testing.

Black Box Testing

In black box testing, the tester has minimal information about the system—typically just the URL of the application and the scope of the engagement. This simulates an external attacker who only knows the main URL of the application.

Steps in Black Box Testing

1. Mapping the Application:

   • Visit the application URL.

   • Navigate through all accessible pages within the given user context.

   • Note all input vectors that potentially interact with the backend.

   • Understand the application's logic, identify subdomains, and enumerate directories and pages not directly visible.

   • Use a proxy to silently intercept and log all requests made to the application.

2. Fuzzing the Application:

   • Add special characters (e.g., quotes, double quotes, hash, dashes) to input vectors and observe if the application responds unusually.

   • Errors are valuable as they reveal information about the backend (e.g., database type, version, exact query).

   • Submit boolean conditions (e.g., 1=1, 1=2) and observe differences in responses to detect boolean injection.

   • Use time delays to see if the application is vulnerable to time-based SQL injection.

   • Submit out-of-band payloads designed to trigger a network interaction with a server you control.

White Box Testing

In white box testing, the tester has complete access to the system, including the source code. This approach involves reviewing the code to identify vulnerabilities.

Steps in White Box Testing

1. Enable Logging:

   • Enable web server logging to capture errors from invalid characters input during fuzzing.

   • Enable database logging to see how inputs are logged in the backend.

2. Mapping the Application:

   • Map the application's graphical user interface to list all visible functionalities and input vectors.

   • Search the source code for instances interacting with the database using regex strings.

3. Fuzzing and Code Review:

   • Submit SQL-specific characters to input vectors and review how they are logged in the backend.

   • If a potential vulnerability is detected, perform a code review of the specific functionality (e.g., login page) to confirm the vulnerability theoretically.

   • Test the suspected vulnerability to confirm it practically.

Conclusion

This methodology combines black box and white box testing perspectives to thoroughly identify SQL injection vulnerabilities. Mapping the application and understanding its logic is crucial in both approaches, as it allows you to identify and test all potential input vectors.

Remember, this methodology is a guideline. Adapt and refine it as you gain more experience in penetration testing web applications.