What this check probes
GET forms and same-origin query links take priority over common root-parameter fallbacks, including id, item, page, q, orderBy, sort and offset. At most one linked catalogue page is fetched for additional discovery. Up to four inputs receive quote probes against the original endpoint baseline.
It looks for database error signatures associated with MySQL, SQL Server, PostgreSQL, Oracle, and SQLite that appear only after the probe. A new HTTP 5xx response without a recognizable database message is reported as a warning for manual review.
When an advertised numeric input is suitable and time remains, one input receives up to seven requests: two original baselines, two true/false pairs with different constants and reversed order, and a literal-input control. The comparison requires complete, non-blocked HTML responses and stable visible content. Script/style size, reflected probe text and raw byte-count differences are not evidence of SQL injection.
A repeatable Boolean content difference is an orange potential blind SQL injection finding, not proof of database execution. Normal application validation can also change a page. Database-specific error findings become red only after the check independently reproduces them.
This is deliberately a low-impact public sample. It does not send data-changing SQL, authentication-bypass strings, OR/UNION queries, or time-delay payloads. All requests share the existing per-check and whole-scan deadlines.
Why this matters for PCI DSS
SQL injection can let an attacker read, modify, or delete application data, including cardholder data and credentials. PCI DSS requires public-facing applications to be protected against common software attacks and requires secure coding techniques for injection flaws.
A pass only means this limited sample did not establish a finding. It cannot rule out blind SQL injection elsewhere. Authenticated pages, POST bodies, JSON APIs and undiscovered endpoints need more extensive application testing. A full ASV scan covers substantially more than this quick check.
How to fix it
Use parameterized queries everywhere. Never concatenate request data into SQL text:
// BAD
var sql = "SELECT * FROM Products WHERE Id = " + Request.QueryString["id"];
// GOOD (.NET Framework / ADO.NET)
using (var cmd = new SqlCommand("SELECT * FROM Products WHERE Id = @id", connection))
{
cmd.Parameters.Add("@id", SqlDbType.Int).Value = productId;
using (var reader = cmd.ExecuteReader())
{
// Read the result.
}
}
Validate input against the expected type, give the application's database account only the permissions it needs, and show generic error pages in production. A web application firewall can add defense in depth, but it does not replace parameterized queries.