🚀 SQL Injection - Part 1: Locating & Exploiting Vulnerable Fields 🚀

Initial Reconnaissance

To begin testing for SQL injection vulnerabilities, I loaded the target web application into OWASP ZAP. Using its automated scanning capabilities, I attempted to identify SQL injection vulnerabilities in various fields across the application. However, ZAP did not return any positive results for SQL vulnerabilities.

Realizing that automated tools can sometimes miss subtle vulnerabilities, I decided to conduct a Static Application Security Testing (SAST) scan using Semgrep with a custom ruleset.

Semgrep did not return explicit vulnerabilities in the SARIF file output, but by manually reviewing the scan results, I identified multiple fields that could potentially be vulnerable. Given these indications, I decided to proceed with manual testing to verify the presence of SQL injection vulnerabilities.

Identifying Vulnerable Fields

Login Form Testing

Password Field: I first tested the password field by attempting SQL injection payloads, but it did not seem vulnerable.

Username Field: I then focused on the username field. Using a fuzzer, I sent a list of 198 SQL payloads to check if any allowed bypassing authentication.

Analyzing Responses: After filtering through the responses, I found that 21 requests returned a successful login status, indicating that the username field was vulnerable to SQL injection, and it let me bypass their login authentication.

Search Field Testing

I moved to the search field on the main page, sending another 198 SQL payloads to check for vulnerabilities.

Upon analyzing the responses, I discovered that 15 of them indicated that the field was vulnerable to SQL injection.

To confirm, I needed to determine the number of columns in the original SQL query. I used:

' UNION SELECT NULL--

' UNION SELECT NULL, NULL--

' UNION SELECT NULL, NULL, NULL

Extracting Usernames and Passwords

Once I confirmed the number of columns, I attempted to extract data from the database by injecting the following SQL payload:

' UNION SELECT username, password, 3 FROM employees;--

I was able to craft this payload by using common tables and columns based on the data I was trying to obtain. This payload took a little while to craft.

This payload was successful and returned a list of usernames and password hashes.

Cracking Extracted Passwords

For example, one of the credentials retrieved was:

Username: itsjasonh

Password Hash: e1fcb3b2c51005c40f7d4d439890453b

The passwords retrieved from the database were stored as MD5 hashes. To convert these hashes into plaintext passwords, I used a hashing tool to reverse the values.

After reverse hashing, I discovered that the password was "badword".

I then proceeded to reverse hash the remaining password values, successfully obtaining plaintext passwords for multiple users.

Key Takeaways

Automated tools like ZAP and Semgrep are valuable but not foolproof—they initially failed to detect SQL vulnerabilities in this application.

Manual testing and fuzzing helped identify critical security flaws in both the login and search fields.

SQL injection can allow attackers to extract sensitive information, including usernames and password hashes.

Weak password storage practices (MD5 hashes) made cracking the passwords trivial—a stronger hashing algorithm should be used.

Next Steps

In Part 2, I will go through mitigation strategies to prevent SQL injection and protect sensitive information. Stay tuned!

If you found this write-up helpful or insightful, please like, comment, and share. Your feedback is always appreciated!

#CyberSecurity #SQLInjection #PenTesting #WebSecurity #EthicalHacking #AppSec #SAST #DAST #Semgrep