Intermittent SQLi and a Flickering Authorization Bug Behind a Blocking WAF

The evidence is suggestive but not yet sufficient: an intermittent timing signal mixed with WAF blocks can be produced by caching, load, or the WAF itself, not only by the database.

Reduce ambiguity first:

• Coordinate with the SOC and application owner before the next window, with a named contact and a stop condition. Confirm the testing source IP is known to the SOC so alerts are not treated as an incident.
• Lower concurrency to well under 10 req/s and add deliberate pacing. Rate-limit pressure is a likely cause of the 403s and of inconsistent timing.
• Establish a baseline distribution: send the benign q value 30 times and record timing percentiles. Without that, a single 9-second response proves nothing.

Then verify with the least intrusive true-positive method available:

1. Prefer a boolean or error-based confirmation if the application exposes one, over more SLEEP calls.
2. If timing is the only channel, alternate a short controlled delay with a matched no-delay control, several times, and compare distributions rather than single samples.
3. Use a delay no longer than necessary (2-3 seconds) to reduce load and timeout risk.
4. Stay read-only. No UNION extraction of real customer data, no stacked queries, no writes.

Record the raw request/response pairs, timestamps, and correlation IDs for each attempt that succeeded, plus the blocked ones. The blocked attempts are part of the evidence, not noise - they explain the intermittency and they show the WAF is the only thing standing between the payload and the database.

Two successes in ten attempts, followed by 403s, in an environment with a 20% canary and an upstream cache, is not yet a finding you can call critical with confidence. It could be a real flaw on the canary version, a caching artefact, or a session/role confusion caused by the test harness. Decide with controlled evidence.

Design a discriminating test:

• Create two test accounts you own in the customer role, with known IDs. Attempt to fetch account B's export while authenticated as A. Never continue once real customer data is displayed - stop, do not save the response body, record only the fact and the correlation ID.
• Capture the response headers that reveal routing: canary markers, cache hit/miss, Via, Age, X-Cache, and any version header. That tells you whether the successes landed on the canary or came from cache.
• Repeat enough times to attribute outcomes to the routing split: if failures cluster on the stable version and successes on the canary, that is a strong signal of a version-specific flaw.
• Test with cache-busting and without, to separate cached object responses from live authorization decisions.
• Check whether the 403s are WAF or application-level; they mean different things.

Decision rule: if you can reproduce cross-account access deterministically against a known version with accounts you control, report as confirmed broken object-level authorization, scoped to that version. If it only occurs intermittently with no version correlation, report as unconfirmed with the evidence and a recommended reproduction plan.

Write for a reader who will ask 'how sure are you?' and will re-test after remediation.

For each finding include:

• Title and classification (CWE-89 for the injection, CWE-639/IDOR for the export) and the affected endpoint and parameter.
• Reproduction conditions: role used, window, source IP, rate, canary percentage, cache state. Intermittent bugs are only actionable if the conditions are documented.
• Evidence: request/response pairs, timing distributions against baseline, correlation IDs, and the count of successful versus blocked attempts. State the denominator honestly - '2 of 10 attempts, both correlated with canary routing' is stronger than 'confirmed'.
• Confidence: confirmed, likely, or unconfirmed. Do not upgrade to confirmed because the report is due.
• WAF context: note that blocking payloads returned 403 and that this is mitigation, not remediation. A WAF rule that blocks your specific payload does not make the parameter safe; a different encoding or a direct-to-origin path may not be blocked.
• Impact framed correctly: for the injection, potential data disclosure from the search backend; for the export, cross-tenant exposure of another customer's data, which carries notification obligations depending on jurisdiction.
• Remediation guidance: parameterized queries, server-side authorization checks on the object owner, cache-control on per-user responses, and tests added to CI so the canary does not ship a regression.