Injection Vulnerabilities (SQLi, NoSQLi, Command Injection, SSTI)
What this domain tests
Injection Vulnerabilities covers SQLi, NoSQLi, command injection, and SSTI. The exam tests context awareness: where input lands, what parser consumes it, and how to prove impact with the least noise.
Core rules and concepts
- Establish the injection context first: string, numeric, JSON, header, filename, or template expression.
- For SQLi, compare boolean truth values, then use UNION with matching column counts, or time-based inference when output is blind. DB-specific syntax matters: MySQL
SLEEP(), PostgreSQLpg_sleep(), MSSQLWAITFOR DELAY. - For NoSQLi, test operator injection in JSON bodies (
$ne,$gt,$regex) and query-string array syntax. - For command injection, use separators (
;,|,&&,$()) and out-of-band callbacks when output is suppressed. - For SSTI, identify the engine with arithmetic and engine-specific syntax: Jinja2/Twig
{{7*7}}, FreeMarker${7*7}, and polyglots for unknown contexts. - Use OAST callbacks to confirm blind command injection and blind SSTI without relying on response timing alone.
Worked example
A JSON login endpoint accepts {'username':'alice','password':'x'}. You send {'username':{'$ne':null},'password':{'$ne':null}} and receive a valid session. The reasoning is that the backend passes the JSON object into a MongoDB query without type enforcement; $ne:null matches the first user. You confirm the bypass is real by repeating with {'username':'alice','password':{'$ne':null}} and by checking that a malformed operator returns a different error.
Traps that cost marks
- Reporting a SQL error as exploitation without a working extraction path.
- Ignoring encoding layers: URL, HTML, JSON, and database quoting.
- Using time delays that are shorter than network jitter.
- Treating
{{7*7}}reflection as RCE; it only proves evaluation.