Web applications process user input to authenticate users, retrieve records, and perform application functions. If input is handled insecurely, specially crafted input may interfere with database queries and create a SQL Injection (SQLi) risk.
In this use case, OWASP Juice Shop is deployed as the intentionally vulnerable target application in an isolated laboratory using Ubuntu Linux and VirtualBox. The Qwen3 Large Language Model (LLM) is used to generate controlled SQL Injection test scenarios, with common SQL Injection samples from a publicly available dataset used as reference examples.
The dataset is used as reference material for scenario generation. The dataset name is not specified in this document, and this use case does not assume that Qwen3 is retrained or fine-tuned on the dataset.
The generated scenarios are reviewed and validated before being submitted to the local application. ModSecurity is configured as a Web Application Firewall (WAF) in front of OWASP Juice Shop, with the OWASP Core Rule Set (CRS) enabled to inspect incoming HTTP requests.
The WAF evaluates requests against its configured rules. Requests matching applicable blocking rules are denied, and relevant security events are recorded in the ModSecurity audit logs.
Kali Linux is used as the security-testing environment. Python is used to organize test scenarios, submit controlled HTTP requests, collect responses, and support result analysis. The test results are correlated with WAF audit logs to assess detection and blocking effectiveness.
The WAF configuration is reviewed to ensure that the protected application is reached through the WAF and that the intended rules and blocking mode are active.
After testing, the generated scenarios, HTTP responses, WAF rule events, and any false positives or inconclusive results are documented. The final assessment distinguishes between a request being blocked, a request being allowed, and a confirmed application-level vulnerability.
Application/Service: OWASP Juice Shop
OWASP Juice Shop is the target web application used for controlled SQL Injection security testing in this use case.
It provides an intentionally vulnerable environment in which application requests and defensive controls can be evaluated without targeting production systems.
SQL Injection can occur when an application handles user-controlled input in a way that allows the input to interfere with database query structure.
Security testing based only on a small collection of predefined requests may not provide sufficient coverage of the input variations that a web application firewall may encounter.
A WAF may detect common SQL Injection patterns, but its effectiveness depends on the request content, active rules, configuration, and how traffic is routed to the application.
AI-generated test scenarios also introduce their own limitations: a generated request may be malformed, irrelevant to the application's endpoints, or fail to exercise a vulnerable code path. Therefore, generated scenarios must be validated and their results must be interpreted using HTTP responses and security logs.
The proposed solution introduces reference-dataset preparation, LLM-based test-scenario generation, scenario validation, controlled request execution, WAF rule enforcement, security-log correlation, and post-test effectiveness evaluation.
Specific Attack: SQL Injection (SQLi)
The controlled attack scenario evaluates how ModSecurity with the OWASP Core Rule Set handles SQL Injection test requests generated with assistance from the Qwen3 LLM.
Common SQL Injection samples from a publicly available dataset are used as reference examples. Qwen3 is prompted to produce additional test scenarios for the authorized laboratory application. The generated output is validated before execution.
Kali Linux provides the security-testing environment for submitting and inspecting authorized test requests. The objective is to evaluate whether the configured WAF detects and blocks applicable test requests and whether the request and rule evidence can be found in the security logs.
This assessment does not assume that every generated request is a working exploit or that every request allowed by the WAF proves a vulnerability.
LLM-Assisted Attack Scenario Generation and WAF Control Validation
The primary security concept is the use of an LLM to assist with test-scenario generation and the use of a WAF to inspect requests before they reach a web application.
The objective is not simply to generate SQL Injection strings. The workflow checks whether generated scenarios are valid for the controlled test, submits them through the configured WAF, and evaluates the observed response together with security-log evidence.
Qwen3 supports the test-generation stage. ModSecurity and the OWASP Core Rule Set provide the defensive inspection and blocking stage. Python supports controlled execution and result collection, while Kali Linux provides the security-testing environment.
The security concept defines the overall testing strategy. The following are the specific defensive mechanisms implemented.
ModSecurity is placed in front of OWASP Juice Shop and inspects incoming HTTP requests.
The OWASP CRS is enabled and configured with applicable SQL Injection detection rules.
ModSecurity is configured to block requests when an applicable rule triggers a blocking action.
Requests for the test application are routed through the WAF-protected endpoint rather than directly to the application.
Qwen3-generated scenarios are reviewed for request format, relevance, and suitability before testing.
Test requests are sent only to the locally deployed OWASP Juice Shop instance in the authorized laboratory.
ModSecurity audit logging is enabled to record relevant rule matches and WAF actions.
Each test request is associated with its HTTP response and corresponding WAF log entry where available.
Benign baseline requests are tested and compared with WAF decisions.
The WAF routing, active rules, and blocking mode are checked after the experiment.
Qwen3 is used to generate SQL Injection test scenarios from common reference examples.
Ollama can run a compatible Qwen3 model locally on Ubuntu, subject to model size and available system resources.
OWASP Juice Shop provides the intentionally vulnerable application used in the controlled test.
Kali Linux provides the security-testing environment used to assess OWASP Juice Shop and inspect application traffic.
Python is used to organize generated test cases, submit requests, collect responses, and analyze results.
Python Requests provides HTTP client functionality for the test harness.
SQLmap is an open-source penetration-testing tool used to assess SQL Injection vulnerabilities in authorized applications.
OWASP ZAP is an open-source web application security testing proxy used to inspect HTTP requests and responses.
ModSecurity is the open-source WAF engine that inspects requests before they reach the target application.
OWASP CRS provides general-purpose web attack detection rules, including rules intended to identify common SQL Injection patterns.
ModSecurity audit logs provide evidence of relevant requests, rule matches, and WAF actions, depending on the logging configuration.
Docker can be used to deploy the target application and compatible supporting components in an isolated environment.
Ubuntu provides the host or virtual-machine environment for the application, model runtime, and testing components.
VirtualBox can be used to isolate the Ubuntu laboratory from other systems and host the Kali Linux security-testing environment.
The Qwen3 LLM generates candidate SQL Injection test scenarios using common SQL Injection samples from a publicly available dataset as reference material.
The generated test scenarios are validated and tested against OWASP Juice Shop in an isolated Ubuntu-based laboratory using Kali Linux as the security-testing environment.
ModSecurity and the OWASP Core Rule Set (CRS) inspect incoming HTTP requests and apply the configured SQL Injection detection and blocking rules.
The WAF blocks requests that trigger applicable blocking rules, while ModSecurity audit logs record relevant rule matches and request-handling actions.
Python is used to collect HTTP responses and correlate them with WAF audit logs to evaluate the observed detection and blocking behavior.
Benign application requests are tested to identify potential false positives and verify that legitimate requests are not unnecessarily blocked.
The assessment records the number of validated test cases, observed blocking results, relevant WAF rule events, and inconclusive outcomes.
The generated scenarios are evaluated for relevance and suitability to identify limitations such as malformed requests, duplicate scenarios, and requests that do not exercise a vulnerable application path.
The experiment demonstrates an AI-assisted security-testing workflow that combines LLM-based scenario generation, Kali Linux testing, WAF enforcement, security logging, and evidence-based evaluation.
The final report documents the laboratory configuration, scenario-generation approach, test results, WAF detection and blocking observations, potential false positives, limitations, and recommendations for further security testing.
Research Breakthrough Possible @S-Logix