Fix Code Vulnerability

Overview

Workflow

Phase 1: Initial Reconnaissance

1. Run existing tests first - Execute the test suite to identify any failing security-related tests. Failing tests often directly indicate what vulnerability needs to be fixed and what behavior is expected.
2. Read failing tests immediately - When security tests fail, read them first before exploring the broader codebase. Tests reveal:
   • The exact vulnerability type (CWE number, attack vector)
   • Expected defensive behavior
   • Specific inputs that should be blocked
   • The API or function under test
3. Identify the vulnerability type - Classify the vulnerability:
   • CWE-89: SQL Injection
   • CWE-78: OS Command Injection
   • CWE-79: Cross-Site Scripting (XSS)
   • CWE-93: CRLF Injection (HTTP Response Splitting)
   • CWE-22: Path Traversal
   • CWE-94: Code Injection
   • CWE-611: XML External Entity (XXE)

Phase 2: Code Analysis

1. Follow the data flow - Trace from user input to the vulnerable operation:
   • Entry points (API endpoints, form handlers, file readers)
   • Data transformation functions
   • Output points (database queries, file operations, HTTP responses)
2. Identify the fix location - Prefer fixing at centralized helper functions rather than multiple call sites:
   • Look for utility functions that process the vulnerable data
   • Fixing a shared helper covers all callers automatically
   • Avoid scattered fixes that may miss edge cases
3. Read code in larger chunks - When analyzing related functions, read them together rather than making many small reads. This provides better context for understanding the code flow.

Phase 3: Implementing the Fix

1. Input validation - For injection vulnerabilities:
   • Validate against dangerous characters (e.g.,

     \n

     ,

     \r

     ,

     \0

     for CRLF)
   • Use allowlists when possible (define what IS allowed vs. what is NOT)
   • Raise clear error messages that identify the issue
2. Output encoding - For XSS and similar:
   • Encode output appropriate to the context (HTML, URL, JavaScript)
   • Use framework-provided encoding functions
3. Parameterization - For SQL/command injection:
   • Use parameterized queries or prepared statements
   • Avoid string concatenation with user input
4. Error handling - Ensure the fix:
   • Raises appropriate exceptions with descriptive messages
   • Does not leak sensitive information in error messages
   • Fails securely (deny by default)

Phase 4: Verification

1. Run the full test suite - All tests should pass, including:
   • The originally failing security tests
   • Existing functionality tests (ensure no regressions)
2. Verify edge cases are covered - Check that the fix handles:
   • All variations of the attack (e.g., all control characters, not just

     \n

     )
   • Both direct and indirect attack paths
   • All methods that could trigger the vulnerability
3. Create a vulnerability report - Document:
   • Vulnerability type and CWE identifier
   • Affected code locations
   • Fix description and rationale
   • Test coverage confirmation

Common Pitfalls

Avoid These Mistakes

1. Incomplete character coverage - When blocking dangerous characters, ensure all variants are covered (e.g., both

   \r

   and

   \n

   for CRLF, not just one).
2. Fixing at wrong level - Don't patch individual call sites when a centralized fix is available. Find the common helper function.
3. Missing indirect paths - A function may be called through multiple code paths. Verify the fix covers all entry points.
4. Skipping test verification - Always run tests after applying fixes. Visual inspection is insufficient.
5. Overly broad fixes - Don't break legitimate functionality. Understand what valid inputs look like before blocking patterns.

Attack Scenarios to Consider

• CRLF Injection (CWE-93): Attacker injects

  \r\n

  to split HTTP headers, enabling response splitting attacks
• SQL Injection (CWE-89): Attacker escapes string context to execute arbitrary SQL
• Command Injection (CWE-78): Attacker uses shell metacharacters to execute system commands
• Path Traversal (CWE-22): Attacker uses

  ../

  sequences to access files outside intended directory

Process Efficiency Tips

1. Start with tests - Running tests first immediately reveals which security checks are failing and what behavior is expected.
2. Read tests before code - Security tests describe the vulnerability and expected fix more clearly than searching the codebase.
3. Fix centralized functions - Identify and fix shared helper functions to cover all code paths with minimal changes.
4. Verify once, comprehensively - Run the full test suite rather than individual tests to catch any regressions.
5. Document the vulnerability - Create a report that explains the vulnerability type, fix applied, and verification performed.