name: vulnerability-analysis description: Expert-level source code security auditing — taint analysis, memory safety, injection classes, auth flaws, crypto weaknesses, concurrency bugs, supply chain risks metadata: type: offensive phase: analysis

Vulnerability Analysis

Every vulnerability you miss is one an attacker can find. Systematic analysis traces untrusted data from source to sink, evaluates filters for bypass, and questions every trust boundary assumption.

When to Activate

- Reviewing any code for security vulnerabilities - Auditing authentication, authorization, or session logic - Evaluating input handling and output encoding - Assessing cryptographic implementations - Reviewing file operations, command execution, or deserialization - Checking for race conditions in concurrent code - Analyzing dependency security and supply chain risks

Core Methodology

Taint Analysis: Mark untrusted data at origin (source), track propagation to dangerous operations (sink). Vulnerability exists when tainted data reaches sink without adequate sanitization.

Source-Forward: Start from data entry points, trace every path to sinks. Comprehensive but time-consuming.

Sink-Backward: Start from dangerous operations (eval, exec, SQL, innerHTML), trace backward to sources. Faster and targeted.

Hybrid Approach: Sink-backward for rapid high-risk identification, then source-forward for complete coverage.

Rule Categories by Priority

Audit Protocol

1. Reconnaissance: Identify language, frameworks, trust boundaries, sensitive data, high-value targets. Establish threat model. 2. Attack Surface Enumeration: Map all entry points — HTTP endpoints, CLI args, file inputs, IPC, deserialization points. 3. Systematic Analysis: Apply hybrid taint analysis across all source-sink paths. 4. False Positive Reduction: - Trace validation chains upstream — is the value bounded before reaching sink? - Confirm reachability — can attacker actually trigger this path? - Evaluate against threat model — does exploitation require capabilities attacker doesn't have? - Check for established patterns — recognized safe idioms in the domain? 5. Exploitability Gate: Before reporting ANY finding: - Are you certain this isn't expected functionality? - Is this a valid vulnerability worth reporting? - Is it actually exploitable in production? 6. Findings: Document CWE, severity, root cause, exploitation scenario, remediation. 7. Variant Hunting: Generalize each finding into a pattern and search for variants.

Vulnerability Classes

Injection Attacks

- SQL Injection: string concat in queries, ORM raw methods, second-order injection - Command Injection: user input in system(), exec(), backticks, $() - XSS: reflected, stored, DOM-based, template injection - SSTI: user input in template engines (Jinja2, Twig, Freemarker) - XXE: XML parsing with external entities enabled - SSRF: user-controlled URLs in server-side requests - Deserialization: untrusted data in pickle, Java ObjectInputStream, PHP unserialize - Path Traversal: ../../../etc/passwd in file operations - ReDoS: catastrophic backtracking in regex with user input

Memory Safety

- Buffer overflow: unbounded copies, integer overflow in size calculations - Use-after-free: dangling pointers, double-free - Integer overflow: unchecked arithmetic in size/offset calculations - Null pointer dereference: missing null checks on fallible operations - Format string: user-controlled format specifiers

Authentication & Authorization

- Auth bypass: missing checks, JWT algorithm confusion, middleware ordering - IDOR: direct object references without ownership verification - Privilege escalation: role checks on client side only - Session fixation: predictable tokens, missing regeneration

Cryptographic Issues

- Weak algorithms: MD5, SHA1 for security, DES, RC4 - ECB mode: pattern-preserving encryption - Missing HMAC: encryption without authentication - Hardcoded keys/IVs: secrets in source code - Insufficient randomness: Math.random() for security tokens

Concurrency

- TOCTOU: check-then-act without atomicity - Race conditions: shared state without proper locking - Double-spend: financial operations without idempotency

Security Review Checklist

- [ ] All user inputs validated server-side with allowlists - [ ] Database queries use parameterized statements exclusively - [ ] Command execution avoids shell interpretation - [ ] Output encoding matches rendering context (HTML, JS, CSS, URL) - [ ] Authentication checks on every sensitive endpoint - [ ] Authorization verifies ownership, not just authentication - [ ] Cryptographic operations use modern algorithms with proper key management - [ ] Session tokens have sufficient entropy with Secure, HttpOnly, SameSite - [ ] File operations validate paths against traversal - [ ] Deserialization never operates on untrusted data without safe loaders - [ ] Race conditions mitigated with atomic operations or proper locking - [ ] Dependencies pinned, audited, free of known CVEs