Injection Vulnerabilities (SQL, NoSQL, LDAP, OS Command)
One class, several grammars
Injection exists wherever data crosses into a parser. Learn the grammar of each one.
SQL: distinguish in-band UNION (match column count and types), error-based, boolean-blind, time-blind, and stacked queries. Know dialect differences - comments (-- , #, /**/), string concatenation, LIMIT syntax, and system table names. Second-order SQLi hides the payload in a stored profile field and fires in a later report. ORM injection occurs when user input reaches whereRaw, extra(), or a dynamic order-by: parameter binding protects values, not identifiers such as column or table names.
NoSQL: operator injection with $ne, $regex, $gt, $where in JSON bodies or bracketed parameters, which turns password[$ne]=x into a match-anything query. Timing and regex-based blind extraction work too.
LDAP: escape sequences like *)(uid=* in filters; test for anonymous binds and attribute-based auth bypass.
OS command: shell metacharacters (;, |, &, $(), backticks, newline), plus argument injection where you cannot break out of quotes but can add flags such as --output or -o to a binary. Blind cases need out-of-band confirmation: DNS or HTTP callbacks, or time delays.
Traps: assuming a WAF stops injection (use case variation, comment insertion, alternate encodings); assuming framework escaping covers identifier positions; forgetting that escapeshellarg still allows argument injection; and missing injection in headers used for logging or in filename generation.
Rule of thumb: find the exact string that reaches the parser, then build the smallest payload that changes the query's logic, and verify with a boolean pair.