Common Exploit Verification

# SQL injection verification and PoC

This is a validation procedure, not a confirmed finding. Under the exploit-verification standard, the issue must not be reported unless the payload reaches the database and produces demonstrable impact. Scanner output or a suspicious query alone is insufficient.

## Candidate finding

**ID:** SQLI-PROFILE-001 (provisional)  
**Vulnerability:** CWE-89: Improper Neutralization of Special Elements used in an SQL Command (SQL Injection)  
**Platform:** Backend API  
**Component:** User profile endpoint; record the exact route and source file/line after tracing  
**Severity:** Unassigned until impact is demonstrated  
**OWASP:** A03:2021 – Injection

## Preconditions

- A test account and authorization token with the least privilege needed to call the profile endpoint.
- A non-production target and a known baseline profile response.
- Permission to inspect application/database logs or query traces.
- The endpoint must accept a user-controlled profile identifier, search value, or other value that is plausibly used in a query.

## Reproducible verification steps

1. Establish a baseline with an ordinary value and save the status, response body, and query/log correlation ID:

   ```sh
   curl -i -sS -H "Authorization: Bearer $TOKEN" \
     --get "$TARGET/api/v1/profile" \
     --data-urlencode "value=test"
   ```

2. Repeat with a syntax-breaking quote. Compare the response and database logs. A generic validation error or a safely handled database error does not prove SQL injection.

3. Repeat with a boolean pair whose only difference is the predicate. Use a harmless test value appropriate to the actual parameter and URL-encode it. For a string context, an example is `test' AND '1'='1'-- ` versus `test' AND '1'='2'-- `. Do not use destructive statements, stacked queries, or production data.

4. Confirm that the true and false cases produce a controlled, repeatable difference attributable to server-side query evaluation. Capture the full HTTP responses, status codes, timing if relevant, and correlated query evidence.

5. Trace the value from the request handler to the database driver. Confirm whether it is concatenated into SQL or passed as a bound parameter. Also check ORM escaping, validation, middleware, WAF behavior, and environment-specific configuration.

**Payload:** Use the exact tested parameter and encoded value; for example, `test' AND '1'='1'-- ` and its false-control counterpart `test' AND '1'='2'-- `. The payload is only evidence when the endpoint’s behavior changes consistently and the change is explained by SQL evaluation.

## Decision

- **Confirmed:** include a finding only if the boolean differential reproduces and the data-flow trace proves attacker input reaches SQL execution unsafely.
- **Conditional:** report with conditions if a specific database mode, race, deployment, or privilege is required.
- **Unconfirmed/discard:** discard after three unsuccessful controlled attempts, or when the value is parameterized, unreachable, escaped by the framework, or blocked by a compensating control.

## False-positive checklist

- Is the flagged code reachable from this endpoint and parameter?
- Is the query generated by an ORM with bound parameters rather than string concatenation?
- Does the actual database driver receive a query template plus a separate parameter array?
- Are middleware, validation, framework defaults, or a WAF preventing the payload from reaching the sink?
- Is the finding based only on an imported vulnerable function or an environment not used by the endpoint?
- Is the apparent difference caused by validation, caching, authorization, or an error path rather than SQL execution?

## Report format if confirmed

Record the exact endpoint/file and line, CVSS based on demonstrated impact, request/response evidence, database evidence, and the affected privilege boundary. Remediate at the query boundary by replacing concatenation with the driver/ORM’s parameter binding, for example:

```ts
// Unsafe
db.query("SELECT * FROM profiles WHERE name = '" + value + "'");

// Safe
db.query("SELECT * FROM profiles WHERE name = $1", [value]);
```

Add a regression test for the true/false payload pair and verify that the response remains constrained. If the exploit cannot be reproduced, the correct output is “unconfirmed—discarded,” not a theoretical SQLi report.