input-validation-injection

name	input-validation-injection
description	Apply when reviewing or writing code that processes untrusted input, constructs queries or commands, or handles user-supplied data. Covers SQL, LDAP, OS command injection, prototype pollution, and general validation strategy.
license	CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/)
metadata	{"origin":"Adapted from CoSAI Project CodeGuard (https://github.com/cosai-oasis/project-codeguard)","category":"secure_development","subcategory":"web-security"}

Input Validation and Injection Defense

Ensure untrusted input is validated and never interpreted as code. Prevent injection across SQL, LDAP, OS commands, templating, and JavaScript runtime object graphs.

Core Strategy

• Validate early at trust boundaries with positive (allow-list) validation and canonicalization.
• Treat all untrusted input as data, never as code. Use safe APIs that separate code from data.
• Parameterize queries/commands; escape only as last resort and context-specific.

Validation Playbook

• Syntactic validation: enforce format, type, ranges, and lengths for each field.
• Semantic validation: enforce business rules (e.g., start <= end date, enum allow-lists).
• Normalization: canonicalize encodings before validation; validate complete strings (regex anchors ^$); beware ReDoS.
• Free-form text: define character class allow-lists; normalize Unicode; set length bounds.
• Files: validate by content type (magic), size caps, and safe extensions; server-generate filenames; scan; store outside web root.

SQL Injection Prevention

• Use prepared statements and parameterized queries for 100% of data access.
• Use bind variables for any dynamic SQL within stored procedures -- never concatenate user input into SQL.
• Prefer least-privilege DB users and views; never grant admin to app accounts.
• Escaping is fragile and discouraged; parameterization is the primary defense.

Example (Java PreparedStatement):

String custname = request.getParameter("customerName");
String query = "SELECT account_balance FROM user_data WHERE user_name = ? ";
PreparedStatement pstmt = connection.prepareStatement(query);
pstmt.setString(1, custname);
ResultSet results = pstmt.executeQuery();

LDAP Injection Prevention

• Always apply context-appropriate escaping:
  • DN escaping for \ # + < > , ; " = and leading/trailing spaces
  • Filter escaping for * ( ) \ NUL
• Validate inputs with allow-lists before constructing queries; use libraries that provide DN/filter encoders.
• Use least-privilege LDAP connections with bind authentication; avoid anonymous binds for application queries.

OS Command Injection Defense

• Prefer built-in APIs instead of shelling out (e.g., library calls over exec).
• If unavoidable, use structured execution that separates command and arguments (e.g., ProcessBuilder). Do not invoke shells.
• Strictly allow-list commands and validate arguments with allow-list regex; exclude metacharacters (& | ; $ > < \ ! ' " ( ) and whitespace when arguments must not contain spaces).
• Use -- to delimit arguments where supported to prevent option injection.

Example (Java ProcessBuilder):

ProcessBuilder pb = new ProcessBuilder("TrustedCmd", "Arg1", "Arg2");
Map<String,String> env = pb.environment();
pb.directory(new File("TrustedDir"));
Process p = pb.start();

Query Parameterization Guidance

• Use the platform's parameterization features (JDBC PreparedStatement, .NET SqlCommand, Ruby ActiveRecord bind params, PHP PDO, SQLx bind, etc.).
• For stored procedures, ensure parameters are bound; never build dynamic SQL via string concatenation inside procedures.

Prototype Pollution (JavaScript)

• Use new Set() or new Map() instead of object literals.
• When objects are required, create with Object.create(null) or { __proto__: null } to avoid inherited prototypes.
• Freeze or seal objects that should be immutable; consider Node --disable-proto=delete as defense-in-depth.
• Avoid unsafe deep merge utilities; validate keys against allow-lists and block __proto__, constructor, prototype.

Caching and Transport

• Apply Cache-Control: no-store on responses containing sensitive data; enforce HTTPS across data flows.

Implementation Checklist

• Central validators: types, ranges, lengths, enums; canonicalization before checks
• 100% parameterization coverage for SQL; dynamic identifiers via allow-lists only
• LDAP DN/filter escaping in use; inputs validated prior to query
• No shell invocation for untrusted input; if unavoidable, structured exec + allow-list + regex validation
• JS object graph hardened: safe constructors, blocked prototype paths, safe merge utilities
• File uploads validated by content, size, and extension; stored outside web root and scanned

Test Plan

• Static checks for string concatenation in queries/commands and dangerous DOM/merge sinks.
• Fuzzing for SQL/LDAP/OS injection vectors; unit tests for validator edge cases.
• Negative tests exercising blocked prototype keys and deep merge behavior.