Injection Vulnerabilities (SQLi, Command Injection, SSTI, LDAP/XPath)
Injection families and context
CWES groups SQL injection, OS command injection, SSTI, and LDAP/XPath injection because the first task is always to identify the interpreter and the syntactic context. SQLi: test quote/comment behavior, then UNION with matching column count, error-based, boolean, time-based, and second-order. Command injection: separators ;, |, ||, &, &&, $(), backticks, newline; confirm blind execution with DNS/HTTP callbacks. SSTI: probe {{7*7}}, ${7*7}, <%= 7*7 %>, #{7*7}; map the engine (Jinja2, Twig, Freemarker, Velocity, ERB) before attempting RCE. LDAP: inject filter metacharacters )(|(uid=* to alter the filter; XPath: inject ' or '1'='1 into the expression.
Worked example
A login form returns a generic "invalid" message. Submitting username ' produces a database error, confirming SQLi. The query is likely SELECT * FROM users WHERE username='...' AND password='...'. Try ' OR 1=1-- - in the username; if the app blocks spaces or comments, use '/**/OR/**/1=1-- - or a time-based payload ' AND SLEEP(5)-- -. If the response is the same but delayed, the injection is blind and time-based. The reasoning: establish syntax, then choose a channel (error, union, boolean, time) that the app actually exposes.
Traps
Assuming every input is SQL; forgetting URL/HTML encoding; not matching column counts; using destructive DROP payloads; missing second-order flows where input is stored and later used in a query; confusing SSTI with client-side template rendering.