Back to Details

fix-code-vulnerability

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Fix Code Vulnerability

修复代码漏洞

Overview

概述

This skill provides a systematic approach for identifying, analyzing, and fixing security vulnerabilities in codebases. It covers common vulnerability types (injection attacks, input validation issues, etc.) and provides verification strategies to ensure fixes are complete and correct.
本技能提供了一套识别、分析和修复代码库中安全漏洞的系统化方法。它涵盖了常见的漏洞类型（注入攻击、输入验证问题等），并提供验证策略以确保修复完整且正确。

Workflow

工作流程

Phase 1: Initial Reconnaissance

第一阶段：初步侦察

Start by understanding the scope and nature of the vulnerability:
  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)
首先了解漏洞的范围和性质：
  1. 先运行现有测试 - 执行测试套件，识别任何失败的安全相关测试。失败的测试通常直接指出需要修复的漏洞类型以及预期的行为。
  2. 立即查看失败的测试 - 当安全测试失败时，先查看测试内容，再探索更广泛的代码库。测试会揭示：
    • 确切的漏洞类型（CWE编号、攻击向量）
    • 预期的防御行为
    • 应被阻止的特定输入
    • 被测试的API或函数
  3. 识别漏洞类型 - 对漏洞进行分类：
    • CWE-89：SQL注入
    • CWE-78：操作系统命令注入
    • CWE-79：跨站脚本攻击（XSS）
    • CWE-93：CRLF注入（HTTP响应拆分）
    • CWE-22：路径遍历
    • CWE-94：代码注入
    • CWE-611：XML外部实体（XXE）

Phase 2: Code Analysis

第二阶段：代码分析

Trace the vulnerable code path:
  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.
追踪存在漏洞的代码路径：
  1. 追踪数据流 - 从用户输入到易受攻击的操作全程追踪：
    • 入口点（API端点、表单处理程序、文件读取器）
    • 数据转换函数
    • 输出点（数据库查询、文件操作、HTTP响应）
  2. 确定修复位置 - 优先在集中式辅助函数中修复，而非多个调用点：
    • 寻找处理易受攻击数据的实用函数
    • 修复共享辅助函数可自动覆盖所有调用方
    • 避免分散的修复，以免遗漏边缘情况
  3. 整体阅读代码 - 分析相关函数时，将它们放在一起阅读，而非多次小范围阅读。这样能更好地理解代码流的上下文。

Phase 3: Implementing the Fix

第三阶段：实施修复

Apply the appropriate defensive measure:
  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)
应用适当的防御措施：
  1. 输入验证 - 针对注入漏洞：
    • 验证危险字符（如CRLF注入中的
      \n
      、
      \r
      、
      \0
      ）
    • 尽可能使用允许列表（定义允许的内容，而非禁止的内容）
    • 抛出清晰的错误消息以指明问题
  2. 输出编码 - 针对XSS及类似漏洞：
    • 根据上下文（HTML、URL、JavaScript）对输出进行编码
    • 使用框架提供的编码函数
  3. 参数化 - 针对SQL/命令注入：
    • 使用参数化查询或预编译语句
    • 避免将用户输入与字符串拼接
  4. 错误处理 - 确保修复：
    • 抛出带有描述性消息的适当异常
    • 不在错误消息中泄露敏感信息
    • 安全失败（默认拒绝）

Phase 4: Verification

第四阶段：验证

Confirm the fix is complete:
  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
确认修复完整：
  1. 运行完整测试套件 - 所有测试都应通过，包括：
    • 最初失败的安全测试
    • 现有功能测试（确保没有回归问题）
  2. 验证边缘情况已覆盖 - 检查修复是否处理了：
    • 所有攻击变体（如所有控制字符，而非仅
      \n
      ）
    • 直接和间接攻击路径
    • 所有可能触发漏洞的方法
  3. 创建漏洞报告 - 记录：
    • 漏洞类型和CWE标识符
    • 受影响的代码位置
    • 修复说明和理由
    • 测试覆盖确认

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.
  1. 字符覆盖不完整 - 阻止危险字符时，确保覆盖所有变体（如CRLF注入中的
    \r
    和
    \n
    ，而非仅其中一个）。
  2. 修复层级错误 - 当存在集中式修复方案时，不要修补单个调用点。找到通用的辅助函数。
  3. 遗漏间接路径 - 一个函数可能通过多个代码路径被调用。验证修复是否覆盖了所有入口点。
  4. 跳过测试验证 - 应用修复后务必运行测试。视觉检查是不够的。
  5. 修复范围过宽 - 不要破坏合法功能。在阻止模式前，先了解有效输入的样子。

Attack Scenarios to Consider

需要考虑的攻击场景

When fixing vulnerabilities, understand the attack:
  • 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
修复漏洞时，要了解攻击方式：
  • CRLF注入（CWE-93）：攻击者注入
    \r\n
    拆分HTTP头，实现响应拆分攻击
  • SQL注入（CWE-89）：攻击者跳出字符串上下文以执行任意SQL语句
  • 命令注入（CWE-78）：攻击者使用shell元字符执行系统命令
  • 路径遍历（CWE-22）：攻击者使用
    ../
    序列访问预期目录之外的文件

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.
  1. 从测试入手 - 先运行测试，可立即发现哪些安全检查失败以及预期的行为。
  2. 先看测试再看代码 - 安全测试比搜索代码库更清晰地描述了漏洞和预期修复。
  3. 修复集中式函数 - 识别并修复共享辅助函数，以最少的变更覆盖所有代码路径。
  4. 全面验证一次 - 运行完整测试套件而非单个测试，以发现任何回归问题。
  5. 记录漏洞信息 - 创建报告，说明漏洞类型、应用的修复以及执行的验证操作。