| name | security-review |
| description | 合并前对代码变更进行安全漏洞审计。在审查 diff / PR、加固代码，或任务提到安全、注入、XSS、SSRF、密钥、认证、反序列化、路径遍历时使用。提供具体清单与汇报格式；永不静默自动修复。 |
安全审查 (Security Review)
针对变更集捕获真实漏洞的聚焦检查清单。先审查 diff（实际变更行及其调用的代码），仅在发现指向别处时才扩大范围。只汇报发现；不修改代码，除非明确要求。
威胁清单（12 项）
1. 注入 (Injection)
不可信输入流入 SQL、Shell、OS 命令、eval、模板引擎或 LDAP。寻找字符串拼接而非参数化查询 / 参数数组。
- 检查点：
exec()、eval()、spawn()、模板字面量拼接 SQL / 命令、shell: true
2. XSS（跨站脚本）
用户数据显示到 HTML / JS / DOM 中未转义。检查 innerHTML、dangerouslySetInnerHTML、未转义的模板插值。
- 检查点：
v-html、innerHTML、insertAdjacentHTML、document.write、直接操作 DOM
3. 认证与授权 (AuthN / AuthZ)
缺少认证、缺少所有权/权限检查、IDOR（按 id 操作对象而不验证调用者持有它）、权限提升、信任客户端提供的角色。
- 检查点：路由未加 middleware、参数中传递用户 ID 而未校验、信任请求体中的
role 字段
4. 密钥泄露 (Secrets)
硬编码的 API Key、Token、密码、私钥或连接串；密钥被日志记录或提交。应从 env / 密钥管理器获取，绝不写入源码。
- 检查点：
sk-、x-api-key、password、secret、token、JWT 密钥、数据库连接串
5. 路径遍历 / 文件访问 (Path Traversal)
用户可控路径未经规范化 / 白名单直接拼接（../ 逃逸、符号链接跟踪）。
- 检查点：
path.join(userInput, ...)、fs.readFile(req.query.file)、文件下载未限定目录
6. SSRF（服务端请求伪造）
向用户提供的 URL / 主机发起服务端请求未做白名单校验；可能访问内部元数据端点。
- 检查点：
fetch(userUrl)、axios.get(userInput)、Webhook URL 未校验
7. 不安全的反序列化 (Deserialization)
不可信数据喂给不安全反序列化器（pickle、原生 YAML loader、Java/PHP 对象反序列化）。
- 检查点：
JSON.parse 本身安全，但 eval() 解析 JSON、yaml.load（非 safeLoad）、pickle.loads
8. 加密缺陷 (Crypto)
弱/自动选择算法（密码用 MD5/SHA1）、硬编码 IV、ECB 模式、缺少 TLS 验证、Token 用可预测随机数。
- 检查点：
Math.random() 用于 Token、createHash('md5') 用于密码、rejectUnauthorized: false
9. 敏感数据暴露
PII / 密钥出现在日志、错误消息或 API 响应中；详细堆栈跟踪泄露给客户端。
- 检查点：
console.log(user)、错误响应中直接返回 err.message、res.status(500).json({ error: err.stack })
10. 依赖安全 (Dependencies)
新增包：是否可信、是否锁定版本、是否有已知 CVE？警惕拼写欺骗。
- 检查点：
npm install 陌生包、pip install 未锁定版本、Dockerfile 中 latest 标签
11. 资源与拒绝服务 (Resource & DoS)
无界循环、无界请求/响应体大小、缺少超时、正则灾难性回溯 (ReDoS)。
- 检查点：
while(true)、正则 /(a+)+b/ 模式、timeout: 0、无 maxBodySize 限制
12. 竞态条件 / TOCTOU
对文件、余额或认证状态的检查-然后-操作，未加锁。
- 检查点：
fs.existsSync 后 fs.writeFile、数据库"读取余额 → 判断 → 扣款"非原子
审查方法
- 识别信任边界：不可信输入从哪里进入？到达了哪些汇聚点（DB、Shell、文件系统、网络、HTML）？
- 追踪污染路径：从源头到汇聚点追踪每个污点值。当它在缺少验证/编码/参数化的情况下到达危险汇聚点时，漏洞成立。
- 偏好白名单而非黑名单；偏好库提供的转义与参数化而非手动消毒。
- 仅标记能用来证明漏洞确实存在的发现——不做推测性、风格化干扰。
输出格式
每项发现按以下格式：
[severity: high|medium|low] <标题>
location: path/to/file.ext:LINE
issue: <出了什么问题，以及触发它的输入>
impact: <攻击者获得了什么>
fix: <最小化的具体修复方案>
按严重度降序排列。如果审查后没有可行动的发现，直说没有——不填充低价值条目。
严重度参考
- high：可直接利用的漏洞，导致数据泄露、服务器接管或认证绕过。必须修复。
- medium：利用有前提条件（需认证、特定配置），但仍构成实际风险。
- low：安全硬化的最佳实践偏差点，无直接利用路径。
规则
- 只审查这次变更引入或修改的代码行，不标记既有问题（可备注但不算本次审查发现）。
- 每条发现必须有具体位置与利用路径——不凭空猜测。
- 永远不静默自动修复安全问题。汇报发现并建议修复，执行留给用户。
