| name | attacker-thinking-primers |
| description | Conceptual mindset primers for reasoning about each major vuln class during live testing (SQLi, auth, info disclosure, access control, API testing, cache deception, request smuggling, Host header, JWT, SSTI, GraphQL, LLM) -- the "why" behind the payload, not another payload list. Converted from master-pentest-prompt.md Phase 21.6. Use alongside the technique-specific skills as a reasoning framework, especially when a class's standard payloads aren't landing. |
Attacker-thinking primers (conceptual knowledge base)
When to use
The payloads live in the technique-specific skills (injection-and-rce,
auth-and-session, etc.) -- this is the reasoning layer underneath them,
most useful when the standard payload list for a class isn't landing and
a different angle is needed.
Primers
- SQLi: any input placed into a query is a candidate. Break structure
first (
'), then control logic (AND 1=1 vs. AND 1=2), then shape
output (UNION, comment-out the rest of the WHERE clause), then go
blind (SLEEP/pg_sleep/behavioral diff), then substring-extract.
Watch for second-order: a payload stored safely that executes later.
- Authentication: find what the app actually uses to prove identity,
then ask whether you can control it -- a cookie, a parameter, a
token, or the order of steps. Test for no lockout on brute force, 2FA
step skipping, a reset token not actually tied to the user it was
issued for, and remember-me cookie forgery.
- Info disclosure: you don't attack this class, you notice it.
Verbose errors, stack traces,
/robots.txt pointing at
/backup/config.php.bak, hidden debug endpoints, .git diffs
containing old credentials, X-Backend-Server headers. Each leak
reduces unknowns -- one leaked header (X-Admin-Auth: true) can bypass
auth entirely on its own.
- Access control: after login, what is actually stopping you from
doing X as another user, or as no user at all? Swap IDs, hit
/admin
directly, change Cookie: role=user to role=admin, method-swap the
privileged action, exploit UI-hidden-but-live endpoints. This class is
simple to exploit because the underlying mistake is simple: the backend
assumed instead of enforced.
- API testing: the same web hacking, minus the UI's restraint. APIs
routinely expose more than the frontend does, trust client-sent
structure over server-side context (
role: "admin" in the body), leak
their own docs (/swagger, /api-docs), accept methods the frontend
never uses, skip rate limiting, and return verbose JSON errors. Ask
"what else will this endpoint accept that the UI never actually sends?"
- Web cache deception: make the cache believe a dynamic,
authenticated page is a static one.
/my-account/wcd.js,
/profile/..%2faccount.css, /settings;file.css -- the backend
normalizes the path and serves the real page, the cache stores it under
the static-looking key. The victim visits while authenticated; you
fetch the same cached response unauthenticated.
- Request smuggling: desync the front-end and back-end on where one
request ends and the next begins (CL.TE/TE.CL/TE.TE/H2 -- see the
request-smuggling skill). Smuggle a request past the front-end for an
access-control bypass, or attach your payload to the next victim's
request for session theft or XSS delivered to everyone behind that
connection. Detect via unexplained timeouts or hangs.
- Host header: changing
Host/X-Forwarded-Host changes how the
server perceives itself. Password-reset link poisoning (the token
points at your server), Host: localhost sometimes grants admin
access, cache poisoning, SSRF via host-based routing.
- JWT: the data is signed, not encrypted -- read it, modify it,
replay it. The core question is always: is the server actually
verifying the signature, or just trusting whatever the client sends?
Test
alg: none, a weak/guessable secret, RS-to-HS confusion,
kid/jku/jwk injection, claim tampering (role: admin), and the
classic server-side RS256->HS256 downgrade.
- SSTI: the input is being rendered as a template, not treated as
data.
{{7*7}} -> 49 proves server-side evaluation is happening.
From there, climb from a simple expression to engine objects to
system() for RCE, or at minimum read files/dump config via a
debug-mode template directive.
- GraphQL: the client decides exactly what it queries.
Introspection gives a full map of queries, mutations, and hidden
fields (including ones like a
password field that shouldn't be
queryable). Ask for fields the UI never shows, try IDOR via ID swap in
variables, use batching/aliases to bypass rate limits, and check for
injection inside arguments. The governing question: "what else will it
return if I just ask?"
- LLM: abuse what the model can see and what it can do -- see the
emerging-surfaces skill's practical probing loop for the concrete
step-by-step version of this primer.
The rule
Never read a class primer without applying it. For each one above,
actually execute it against the target's matching endpoints before
moving on to the next -- this is a reasoning checklist to act on, not
background reading.
