Injection Vulnerabilities
Injection Vulnerabilities spans SQLi, NoSQLi, command injection, SSTI, and LDAP/XPath injection. CWEE tests whether you can identify the interpreter behind an input, choose a payload appropriate to that context, and demonstrate controlled impact.
Identify context first
For SQLi, distinguish string, numeric, and ORDER BY contexts. Use error-based, boolean, time-based, and UNION techniques as appropriate. For NoSQL, test operator injection such as {"$ne":null} and array parameters. Command injection needs separator testing (;, |, &&, newline) and blind confirmation via timing or out-of-band DNS. SSTI requires engine fingerprinting: {{7*7}} for Jinja/Twig, ${7*7} for Freemarker, and <%= 7*7 %> for ERB. LDAP injection targets filter syntax with *, )(, and |.
Worked example
A search parameter reflects 49 when submitted as {{7*7}}. That confirms Jinja-style SSTI. Escalating with {{config.__class__.__init__.__globals__['os'].popen('id').read()}} returns command output. The finding is not "template injection"; it is remote code execution through SSTI, and remediation is to stop rendering user input as templates.
Traps
A WAF block does not mean the parameter is safe; encoding and alternate syntax matter. UNION requires matching column counts and compatible types. Time-based tests need repeated baselines to avoid false positives. NoSQL operators may need JSON content types. Blind command injection should use a unique canary, not a destructive command.