/hunt-sqli

name: hunt-sqli
description: SQLi and NoSQLi hunting - error-based, boolean-blind, time-based, UNION, NoSQL operator injection. sqlmap automation after manual confirmation. Wiki-first, FIND schema output.

Hunt: SQL Injection

**Assumes `hunt-core`** for the scope gate, two-account rule, confirmation gate, enumeration limits, stop conditions, wiki protocol, FIND output, and Deadends. Do not re-derive any of that here.

Wiki

qmd_query "SQL injection SQLi NoSQL union boolean-blind time-based error-based" via wiki-search MCP

Hub: [[web-moc]] (live web index). Primary page: [[sql-injection]]. Payload arsenal: `wiki/payloads/sqli.md`. Anchors: [[nosql-injection]], [[orm-injection]].

Confirmation gate

**NOT confirmation:** a generic `500`; a WAF block page or a "SQL injection detected" string (that is the app's filter firing, not the database); a reflected error string you have not proved originates from the DB; a single non-repeatable slow response; a boolean or time inference with no differential (no clean baseline-vs-injected delta); the payload echoed back from your own request; any verdict read off a response body without a clean-session re-verify.

**IS confirmation:** a DB error whose text is demonstrably from the engine (`extractvalue`/`updatexml` output, a driver error naming the DBMS); UNION or error-based output that returns real DB content; a boolean oracle that flips TRUE/FALSE consistently across probes; a time delta that reproduces on repeat (baseline vs `SLEEP(5)`/`pg_sleep(5)`/`WAITFOR`, re-run); or an out-of-band DNS/HTTP hit to your unique Collaborator/interactsh subdomain. Re-verify in a CLEAN session every time; on a login-redirect oracle clear the session cookie between probes (a stale authenticated session reads as always-true).

**Out-of-band (blind SQLi via DNS/HTTP).** When you plant a blind/OOB payload, append a row to `targets/<eng>/oob.md`: `| <token> | <sink url+param> | sqli | <date> | waiting | |` (columns: token | sink | class | planted | status | source, token = your unique Collaborator/interactsh label). Exfil sinks: MySQL `LOAD_FILE`/UNC path, MSSQL `xp_dirtree`, Oracle `UTL_HTTP`. The recon-capture hook auto-correlates the callback to flip the row to HIT and SessionStart surfaces HITs; a `HIT row` is the gate to scaffold the FIND. **Do NOT claim a blind** SQLi without a HIT row.

Attack surface

Highest-value injection points first:

• **Authentication / login** - a bypass here is auth bypass; the login-redirect oracle (below) turns even a filtered, output-less login into a blind extractor.
• **Search / filter / sort / report params** - `?q=`, `?category=`, `?sort=&order=` (ORDER BY injection), `?start_date=`; user input lands straight in a WHERE/ORDER BY.
• **Anything that reflects query output or a DB error** - error-based and UNION need a reflection sink; if the page you are hitting reflects nothing, test on one that does.
• **JSON bodies with nested objects** - operator injection -> NoSQL (`{"$gt":""}`, `[$ne]`).
• **Second-order sinks** - a value stored safely at register/login but rendered unsafely elsewhere (profile, dashboard, "last logins").
• **Headers, cookies, path segments** - the least-tested vectors; ORDER BY / LIMIT clauses frequently take raw input.

URL patterns:

/search?q=  /filter?category=  /sort?by=&order=  /report?start_date=
/api/v1/items?id=  /index.php?id=  /gallery?album_id=  ?page=&limit=

Fingerprint the DB: PHP + Apache -> MySQL; Express + MongoDB -> NoSQL; `application/json` with nested objects -> potential NoSQL.

Methodology

**Order: in-band before blind.** Try error-based and UNION (direct data/errors) BEFORE boolean/time-based - blind is slow and easily masked (e.g. an anti-bruteforce `SLEEP()` on the login page adds a constant delay that hides your injected `SLEEP`). UNION/error need a place where query output or a DB error is REFLECTED; if the page you are hitting reflects nothing, test the SQLi on a different page that does.

1. Enumerate all input vectors (GET, POST, JSON body, headers, cookies, path segments). 2. Baseline the response (length, status, time). 3. Error probes in **every quote context** - `'` `"` `` ` `` `')` `"))` and numeric/no-quote. A `'` doing nothing does NOT mean safe: the sink may be double-quoted (`WHERE x="$v"`). Watch for a reflected DB error or any length change. **On a numeric-looking id param, test the NUMERIC context FIRST** with a boolean pair - `id=1 AND 1=1` (row shows) vs `id=1 AND 1=2` (row gone). That one request pair settles the context before you burn turns theorizing quote/`LIKE` breakouts; a `'` that only errors can be a WAF/troll page, not the real query shape. 4. In-band first: error-based (`extractvalue`/`updatexml`) and UNION (`ORDER BY` for col count, then `UNION SELECT`). Mind display truncation when sizing extracted chunks. 5. Only then blind: boolean (`AND 1=1` vs `AND 1=2`) then time (`SLEEP(5)`/`pg_sleep(5)`/`WAITFOR`). 6. **Second-order:** if login/register is parameterized, the SAME stored value may be unsafe on another page (profile/dashboard/"last logins") OR simply wherever the app echoes your stored name back - a greeting, a "Welcome X", a counter/result line. Register the payload as the username, log in, then load the page that renders it - and READ THE WHOLE reflected block, not a keyword grep: the phrasing can shift (singular "1 word" vs plural "N words") and hide the dumped data. This class is rare and under-tested, so it is easy to walk past - always try it before concluding a parameterized login is safe. See the PROCESSLIST section below. 7. NoSQL (MongoDB): replace value with `{"$gt": ""}` or `param[$ne]=invalid`. 8. **Tool-first for the dump, always.** Confirm manually in 1-2 requests only (e.g. an arithmetic tell: `id=2-1` evaluates to row 1 = injection proven) - the NEXT step is sqlmap, never a hand-rolled `group_concat`/`LIMIT` paging loop to extract the data yourself: `