SQL Injection has been detected on a request that did not access the database

SQL Injection is the vulnerability that allows an attacker to perform unauthorized operation on a database. Even if detected, it can be identified as a false positive as long as a DB has not been accessed by the detected parameter.

When it is difficult to identify, see How Vex detects SQL Injection and Verification steps for SQL Injection below.

[How Vex detects SQL Injection]
Vex signatures for "SQL Injection" detects the vulnerability based on the two aspects below.

(1) Whether or not an SQL error occurs when sending a payload

If an SQL error occurs in the response when sending a payload, Vex detects it because SQL may be manipulated depending on the value of the parameter.

(2)Whether or not there is a response difference when sending a payload

In some applications, when an SQL error occurs, the SQL error message may not appear in the response (i.e. Blind SQL Injection). In that case, Vex checks the response difference to determine if there is the vulnerability.

Vex sends following payloads in order,and it is judged as the vulnerability detected if there is a large difference between the responses when the incorrect pattern is sent (*1) and when the correct pattern is sent (*2) as SQL syntax. 
*1 Assuming an error screen provided by applications.
*2 Assuming a normal screen same as ones obtained when getting the proxy log

<Payloads>
Pattern A: No payload (same request as the proxy log)
Pattern B: Incorrect SQL syntax
Pattern C: Correct SQL syntax
Pattern D: Incorrect SQL syntax

The possibility of false positives for (1) is relatively low, but in case of (2), false positives may occur depending on the behavior of the target server.

[Verification steps for SQL Injection]
The verification steps are described below.
*It is applicable to both (1) and (2) described above.

*Test access must be successful to perform the verification steps properly,  so be sure to confirm that Test access is successful before proceeding the steps.

1. Resend the scan result
Click "Resend" in the relevant scan result.
*If no vulnerability is detected by re-sending, it is considered a false positive.
If detected, follow the steps below.

2. Open the list of scanning results in the "Results" and click "Detail" of the relevant result to open the "Scanning result" tab.
3. See "Detected reason" in the "Scanning result" tab, and continue the verification by following the one of the instructions below that correspond to your case.

■A value is shown in Detected reason
If the value shown is an error message attributable to SQL, the vulnerability is detected.
(If the value is not attributable to SQL, consider it as a false positive).

■A value is not shown in Detected reason
a. Open the "Parent scanning result ID" link in a new tab.

b. Open the "Parent scanning result ID" link in a new tab from the opened scanning result tab.
*Repeat this until the Parent scanning result ID link is no longer shown.

c. Compare each "Changed value" (the inserted payloads) with the response content. If the response   difference is caused depending on the correctness/incorrectness of the SQL syntax, the vulnerability is detected.
If the response difference is caused by other than SQL, such as WAF or other defense mechanisms, it is a false positive.