Every classic SQLi technique failed on this endpoint, and the vuln was still real

Testing an internal reporting endpoint for SQLi: pass a customer ID, get back a PDF. Error-based went nowhere first, the app wraps every database call in a try/catch and returns the same generic "report unavailable" page no matter what breaks. So I moved to boolean-based blind, injecting a condition that should flip the response between true and false. Still nothing, because it turned out the injectable parameter only fed an internal audit log write, not the query deciding what actually got rendered. True or false, the customer sees the exact same PDF.

Time-based felt like the obvious fallback at that point. Inject a payload that stalls the query five seconds if true, nothing if false, and watch the response time. Except there's a reverse proxy in front of this app enforcing a three-second upstream timeout, and it fires on every request past that mark regardless of what the backend is doing. True and false conditions both came back as the same 504 around the same three seconds. The one timing signal time-based blind needs had been erased by infrastructure that has nothing to do with the actual vulnerability.

Three of the four classic SQLi techniques dead on one endpoint, and none of them failed because the injection wasn't real. They failed because nothing about this endpoint gives you a signal you can read back through the HTTP response at all.

That's the specific gap out-of-band SQL injection fills. Instead of trying to read the result of an injected query in the page, you make the database originate a network request you can observe somewhere else entirely. On MSSQL, procedures like xp_dirtree or xp_fileexist pointed at a UNC path trigger a DNS lookup against a domain you control, one that can encode the extracted data straight into the subdomain. On Oracle, functions like UTL_HTTP or UTL_INADDR can be chained inside a crafted injection to make the database originate an outbound request the same way. You're not reading the answer in the response anymore. You're reading it in your own DNS server's query log a few minutes later, long after the request that triggered it already came back with its identical, useless 504.

Sqlmap has a –dns-domain flag built around exactly this exchange: point it at a domain whose nameserver you control and it automates the DNS-lookup exfiltration loop instead of you hand-crafting individual xp_dirtree calls.

What actually stuck with me from this one: in-band, blind, and out-of-band aren't three unrelated party tricks, they're the same underlying question, how do I get data out of this database, answered under three different constraints on what's actually observable. Figuring out which constraint you're under beats retrying time-based blind for the tenth time against a proxy that's already eating your signal.

Codelivly's SQL Injection Notes PDF walks through in-band, blind, time-based, and out-of-band SQLi as one connected methodology, with the database-specific payloads and sqlmap workflows for each, instead of treating OOB like a footnote you only hear about once everything else has already failed.

If you want to build the pattern-recognition hands-on first, Codelivly also has a free SQLi Login Bypass lab and a NimbusPay SQL Injection CTF challenge.