security-review

name	security-review
description	合并前审计代码变更的安全漏洞。用于审查 diff/PR、加固代码，或任务提及"安全""注入""XSS""SSRF""密钥""认证""反序列化""路径遍历""这安全吗"时使用。提供具体检查清单和报告格式；绝不静默自动修复。
license	MIT
compatibility	kimi-cli
metadata	{"audience":"reviewers","workflow":"security"}

安全审查

聚焦于在变更集中发现真实漏洞的检查清单。先审查 diff（实际变更的行及其调用的代码），仅在发现指向其他位置时才扩展范围。报告问题；除非明确要求，不修改代码。

威胁检查清单

• 注入 — 不受信输入流入 SQL、shell、OS 命令、eval、模板引擎、LDAP。检查字符串拼接替代参数化查询/参数数组。
• XSS — 用户数据未经转义渲染到 HTML/JS/DOM。检查 innerHTML、dangerouslySetInnerHTML、未转义模板插值。
• 认证/授权 — 缺少认证、缺少所有权/权限检查、IDOR（通过 id 操作对象但未验证调用方拥有该对象）、权限提升、信任客户端提供的角色。
• 密钥 — 硬编码的 API key、token、密码、私钥、连接字符串；密钥被记录或提交。应从 env/密钥存储获取。
• 路径遍历/文件访问 — 用户控制的路径未经规范化/白名单即拼接（../ 逃逸、符号链接跟踪）。
• SSRF — 服务端请求发往用户提供的 URL/主机，未做白名单限制；可能到达内部元数据端点。
• 反序列化/解析 — 不受信数据喂给不安全反序列化器（pickle、原生 YAML 加载器、Java/PHP 对象反序列化）。
• 加密 — 弱/自动算法（MD5/SHA1 用于密码）、硬编码 IV、ECB 模式、缺失 TLS 验证、用可预测随机数生成 token。
• 敏感数据暴露 — PII/密钥出现在日志、错误消息或 API 响应中；详细堆栈跟踪泄露给客户端。
• 依赖 — 新增包：是否可信、是否锁定版本、是否无已知 CVE。
• 资源与 DoS — 无界循环、无界请求/消息体大小、缺失超时、正则灾难性回溯（ReDoS）。
• 竞态条件/TOCTOU — 对文件、余额或认证状态的检查后操作，无锁保护。

方法

1. 识别信任边界：不受信输入从哪里进入，在哪里到达汇点（DB、shell、文件系统、网络、HTML）。
2. 追踪每个被污染值从源到汇；当它在没有验证/编码/参数化的情况下到达危险汇点时有漏洞存在。
3. 优先白名单而非黑名单；优先库提供的转义和参数化而非手动净化。
4. 仅标记能用具体利用路径证明的问题——不做推测性或纯风格噪音。

报告格式

每个发现：

[severity: high|medium|low] <标题>
location: file:line
issue: <问题所在及触发的输入>
impact: <攻击者获得什么>
fix: <最小具体修复方案>

按严重度排序。如果审查后未发现可操作的问题，明确说明而非用低价值注释填充。