Back to Details

deep-audit

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Deep Audit

深度审计

Phase 1: Discovery

第一阶段：发现

Map the entire codebase. Leave nothing unexplored.
Actions:
  1. Recursively list all directories and files
  2. Identify: languages (by extension), frameworks (by config files), dependencies (by manifests)
  3. Locate entry points: main files, route handlers, API endpoints, CLI parsers
  4. Map trust boundaries: where external input enters, where data exits
Output: Mental model of architecture, data flow, and attack surface.
全面映射整个代码库，不放过任何内容。
操作：
  1. 递归列出所有目录和文件
  2. 识别：编程语言（通过文件扩展名）、框架（通过配置文件）、依赖项（通过清单文件）
  3. 定位入口点：主文件、路由处理器、API端点、CLI解析器
  4. 绘制信任边界：外部输入的进入位置、数据的输出位置
输出： 架构、数据流和攻击面的心智模型。

Phase 2: Audit Plan

第二阶段：审计计划

Build a targeted checklist. Prioritize by risk.
CategoryHunt for
InjectionUnsanitized input → command execution, query construction, path building, template rendering
Auth/AuthZMissing checks, weak tokens, session fixation, privilege escalation, IDOR
CryptoBroken algorithms, hardcoded keys, predictable randomness, missing encryption
SecretsCredentials in code, keys in configs, tokens in logs, env vars with defaults
ValidationType confusion, integer overflow, buffer issues, missing bounds checks
ErrorsStack traces exposed, debug flags, verbose logging, unhandled exceptions
DataPII in logs, sensitive data unencrypted, insecure deserialization
DependenciesKnown CVEs, outdated packages, typosquatting
ConcurrencyRace conditions, TOCTOU, deadlocks, shared state mutations
LogicBusiness logic bypasses, state machine violations, trust assumption failures
Rank by: Exploitability × Impact × Exposure
制定针对性检查清单，按风险优先级排序。
类别检查内容
注入攻击未经过滤的输入 → 命令执行、查询构造、路径构建、模板渲染
认证/授权缺失检查、弱令牌、会话固定、权限提升、IDOR（不安全的直接对象引用）
加密机制破损算法、硬编码密钥、可预测随机性、缺失加密
敏感信息代码中的凭据、配置中的密钥、日志中的令牌、带默认值的环境变量
验证机制类型混淆、整数溢出、缓冲区问题、缺失边界检查
错误处理暴露堆栈跟踪、调试标志、详细日志、未处理异常
数据安全日志中的个人可识别信息（PII）、敏感数据未加密、不安全的反序列化
依赖项已知CVE漏洞、过时包、打字错误仿冒包
并发问题竞态条件、TOCTOU（检查时间与使用时间不一致）、死锁、共享状态突变
逻辑缺陷业务逻辑绕过、状态机违规、信任假设失效
排序依据： 可利用性 × 影响范围 × 暴露程度

Phase 3: Deep Analysis

第三阶段：深度分析

Hunt relentlessly. Every file. Every function. Every input path.
全面排查，覆盖每个文件、每个函数、每个输入路径。

3.1 Secrets Scan

3.1 敏感信息扫描

Search entire codebase for:
  • password
    , 
    secret
    , 
    api_key
    , 
    token
    , 
    credential
    , 
    auth
  • -----BEGIN
    , 
    PRIVATE KEY
    , 
    ssh-rsa
  • Base64 blobs (40+ chars), hex strings (32+ chars)
  • Connection strings, DSNs, URIs with credentials
Verify each hit. False positive? Move on. Real secret? Flag as CRITICAL.
搜索整个代码库中的以下内容：
  • password
    、
    secret
    、
    api_key
    、
    token
    、
    credential
    、
    auth
  • -----BEGIN
    、
    PRIVATE KEY
    、
    ssh-rsa
  • Base64 blob（40字符以上）、十六进制字符串（32字符以上）
  • 包含凭据的连接字符串、DSN、URI
验证每个匹配项。 误报？跳过。真实敏感信息？标记为CRITICAL（严重）。

3.2 Injection Analysis

3.2 注入攻击分析

Trace every input source to every dangerous sink:
  • Sources: HTTP params, headers, body, files, env vars, CLI args, database reads, IPC
  • Sinks: Command execution, SQL/NoSQL queries, file operations, template engines, serializers, network calls
For each source→sink path: Is there sanitization? Is it sufficient? Can it be bypassed?
追踪每个输入源到每个危险的输出点：
  • 输入源： HTTP参数、请求头、请求体、文件、环境变量、CLI参数、数据库读取、进程间通信
  • 输出点： 命令执行、SQL/NoSQL查询、文件操作、模板引擎、序列化器、网络调用
对于每个“输入源→输出点”路径：是否有过滤处理？过滤是否充分？是否可被绕过？

3.3 Auth & Access Control

3.3 认证与访问控制

  • Find all endpoints/functions requiring auth. Verify enforcement.
  • Check for horizontal privilege escalation (user A accessing user B's data)
  • Check for vertical privilege escalation (user becoming admin)
  • Look for auth bypasses: default credentials, magic parameters, debug routes
  • 找出所有需要认证的端点/函数，验证是否强制执行认证。
  • 检查横向权限提升（用户A访问用户B的数据）
  • 检查纵向权限提升（普通用户成为管理员）
  • 查找认证绕过方式：默认凭据、魔术参数、调试路由

3.4 Crypto Review

3.4 加密机制审查

  • List all crypto operations. Verify algorithms are current.
  • Check key generation: is randomness cryptographically secure?
  • Check key storage: hardcoded? plaintext? properly protected?
  • Verify encryption modes (no ECB), proper IV/nonce usage, authenticated encryption
  • 列出所有加密操作，验证算法是否为当前安全标准。
  • 检查密钥生成：随机性是否符合密码学安全要求？
  • 检查密钥存储：是否硬编码？是否明文存储？是否得到妥善保护？
  • 验证加密模式（禁止使用ECB）、IV/nonce的正确使用、带认证的加密

3.5 Error & Exception Handling

3.5 错误与异常处理

  • Search for exception handlers. Are they too broad? Do they leak info?
  • Check HTTP error responses for stack traces, internal paths, versions
  • Look for debug/dev mode flags still enabled
  • Find logging statements with sensitive data
  • 搜索异常处理器：是否过于宽泛？是否泄露信息？
  • 检查HTTP错误响应是否包含堆栈跟踪、内部路径、版本信息
  • 查找仍启用的调试/开发模式标志
  • 查找包含敏感数据的日志语句

3.6 Dependency Audit

3.6 依赖项审计

  • Extract all dependencies with versions
  • Check each against known vulnerability databases
  • Flag outdated packages (>1 year without update = suspicious)
  • Look for vendored/copied code that may have unpatched vulns
  • 提取所有带版本号的依赖项
  • 对照已知漏洞数据库检查每个依赖项
  • 标记过时包（超过1年未更新则视为可疑）
  • 查找可能存在未修补漏洞的 vendored/复制代码

3.7 Logic & State

3.7 逻辑与状态

  • Identify state machines. Can states be skipped or forced?
  • Check financial/critical operations for race conditions
  • Verify atomic operations where needed
  • Look for time-of-check-time-of-use issues in file/resource access
  • 识别状态机：是否可跳过或强制切换状态？
  • 检查财务/关键操作是否存在竞态条件
  • 验证必要的原子操作
  • 查找文件/资源访问中的TOCTOU问题

Phase 4: Report

第四阶段：报告

No fluff. Facts only.
markdown
undefined
拒绝冗余，只列事实。
markdown
undefined

Security Audit Report

安全审计报告

Executive Summary

执行摘要

  • CRITICAL: [count]
  • HIGH: [count]
  • MEDIUM: [count]
  • LOW: [count]
  • CRITICAL: [数量]
  • HIGH: [数量]
  • MEDIUM: [数量]
  • LOW: [数量]

Findings

发现的问题

[CRITICAL] Title

[CRITICAL] 标题

File: 
path/to/file:line
Issue: [One sentence] Evidence: [Code block] Impact: [What attacker gains] Fix: [Specific remediation]
[Repeat for each finding, highest severity first]
文件： 
path/to/file:line
问题： [一句话描述] 证据： [代码块] 影响： [攻击者可获得的权限/利益] 修复方案： [具体的补救措施]
[按最高严重度到最低，重复上述格式列出每个问题]

Attack Scenarios

攻击场景

[2-3 realistic attack chains combining findings]
undefined
[2-3个结合多个问题的真实攻击链]
undefined

Rules

规则

Do not act like typical AI slop. No lazy pattern matching. No surface-level scanning. No generic findings.
不要像普通AI那样敷衍了事。 拒绝懒惰的模式匹配，拒绝表面扫描，拒绝通用化的发现结果。

Bug or Feature?

是缺陷还是特性？

Before flagging ANYTHING, run this verification:
  1. Context check. Read surrounding code. Read comments. Read commit history if available.
  2. Intent check. Could this be deliberate? Is there a security/usability tradeoff being made?
  3. Documentation check. Is this behavior documented? Is it a known limitation?
  4. Pattern check. Does similar code exist elsewhere? Is this project's convention?
  5. Edge case check. Does this only fail under unrealistic conditions?
Ask yourself: Is this really a bug, or am I misunderstanding the design?
Only flag when you can answer:
  • Why this is NOT intentional
  • Why existing mitigations (if any) are insufficient
  • What realistic attack scenario exploits this
在标记任何内容之前，执行以下验证步骤：
  1. 上下文检查。 阅读周边代码、注释，若有可用提交历史也需查看。
  2. 意图检查。 这是否是故意设计的？是否存在安全与易用性的权衡？
  3. 文档检查。 此行为是否有文档说明？是否是已知限制？
  4. 模式检查。 项目中是否存在类似代码？这是否是项目的惯例？
  5. 边缘情况检查。 这是否仅在不切实际的条件下才会失效？
自问： 这真的是缺陷，还是我误解了设计？
仅当你能回答以下问题时，才进行标记：
  • 为什么这不是故意设计的
  • 为什么现有的缓解措施（如果有）不够充分
  • 什么样的真实攻击场景会利用这个问题

Core Rules

核心规则

  1. Verify everything. Read the actual code. No guessing.
  2. Trace data flow. Follow inputs to outputs. Miss nothing.
  3. Attack mindset. What would you exploit? How?
  4. Quality over quantity. One confirmed vuln > ten maybes.
  5. Precision. File:line, exact code, specific impact.
  6. Actionable. Every finding has a concrete fix.
  7. No false positives. When uncertain, investigate deeper—don't flag.
  1. 验证所有内容。 阅读实际代码，拒绝猜测。
  2. 追踪数据流。 从输入到输出全程跟踪，不遗漏任何环节。
  3. 攻击者思维。 你会利用什么？如何利用？
  4. 质量优先于数量。 一个已确认的漏洞胜过十个疑似问题。
  5. 精准定位。 明确文件:行号、准确代码、具体影响。
  6. 可执行性。 每个发现的问题都有具体的修复方案。
  7. 拒绝误报。 若有疑问，深入调查——不要标记。