TL;DR

A comprehensive guide for exploring how to test for SQL injection vulnerabilities in web applications. It covers steps such as selecting parameters for testing (e.g., URL query, POST body), performing basic math tests, adding common symbols, testing for multiple symbols, and injecting SQL query functions. Additionally, it demonstrates the use of comments to hide malicious payloads and suggests using specialized tools like SQLMap for advanced testing. Detecting and addressing SQL injection vulnerabilities is crucial for web application security.

Trust me, it really feels good when you see this the below screenshot on your target application and why not? SQL injection vulnerabilities generally are a valid P1 issues on bug bounty programs.

It becomes easy to find SQL Injection if we understand, How an application behaves in response to different HTTP requests and inputs. It’s essential to understand how SQL injection works and how to test for it effectively.

This guide will take you through the step-by-step process of testing for SQL injection vulnerabilities.

1. Select Parameters for Testing

Before diving into SQL injection testing, identify the parameters you want to test. These parameters can be found in various places within a HTTP request that is sent to an application server:

• URL query

• POST body

• Headers

• Cookies

Choose any parameter, but it’s common to start with integer parameters. These are often used in queries and can be more susceptible to SQL injection.

2. Perform Basic Math Tests

If the selected parameter is an integer, try performing basic math operations on it within the input:

Example: user_id=1338-1

If an SQL injection vulnerability exists, you might observe unexpected results or errors in the response.

3. Add Common Symbols

Next, add common SQL injection symbols to the parameter and monitor the response status. Some symbols to test include:

• Single quote (')
• Double quote (")
• Semicolon (;)

If you receive an error response, this could be a sign of an SQL injection vulnerability.

4. Test for Multiple Symbols

Continue testing by adding more than one symbol to the parameter to see how the application responds. For SQL, the escape character for a single quote is another single quote, and for a double quote, it’s another double quote.

Examples:

• login=admin (status: 200)
• login=admin' (status: 500)
• login=admin'' (status: 200)

5. Perform SQL Query Functions

Try injecting SQL query functions into the parameter. Depending on the type of parameter (integer or text), use appropriate functions:

Integer Parameter:

• user_id=1337 AND 1=1 (status: 200)
• user_id=1337 AND 2=1 (status: 500)

Text Parameter:

• login=admin' AND 'A'='A (status: 200)
• login=admin' AND 'A'='B (status: 500)

JSON Integer Parameter:

• {"user_id":"1337 AND 1=1"} (status: 200)

6. Combine SQL Query Functions with Comments

To hide your malicious payload, add comments at the end of the parameter:

Examples:

• Integer Parameter: user_id=1337 AND 1=1 -- (status: 200)
• Text Parameter: login=admin' AND 'A'='A' -- (status: 200)
• JSON Integer Parameter: {"user_id":"1337 AND 1=1 --"} (status: 200)
• JSON Text Parameter: {"login":"admin' AND 'A'='A' --"} (status: 200)

7. Use Specialized Tools for Further Testing

Once if the vulnerable parameter is identified, exploitation could be done with specialized tools like SQLMap or Ghauri. These tools can automate the testing process and provide detailed results.

After holding a proper understanding of what input fields needs to be tested, the process of crawling, collecting different HTTP requests and testing input fields could be done in a automated fashion. Several tools like waybackurl, gau, Burpsuite (All requests from the History tab), Nuclei, SQLMap or Ghauri.