安全风险扫描器 (Security Risk Scanner)

> 「不仅查能不能被攻破，也查能不能被打瘫」 — 覆盖 OWASP Top 10 全谱系 + 资源滥用风险的全项目静态安全审查。

核心理念

这个 skill 不是泛泛的代码审查，而是聚焦安全风险的静态扫描：

• 传统安全审查只查注入、认证、加密（Anthropic 官方 security-review 即如此，明确排除 DoS/Rate Limiting）
• 本 skill 在传统审查基础上，额外覆盖官方排除的资源滥用类风险（服务器并发、API 限流、文件上传滥用、前端无限访问）

差异定位：

触发规则

扫描范围：默认全项目；用户可指定子目录（如「只查 src/api/」）

适用平台：Trae、Claude Code、WorkBuddy 等跨平台 AI 编码助手

三阶段扫描流程

Phase 1 — 项目侦察（Reconnaissance）

在动手审查前，先了解项目的安全底座：

1. 识别技术栈
   - 后端框架（Express/NestJS/Spring Boot/FastAPI/Django/Gin 等）
   - 前端框架（React/Vue/Angular/Next.js/Nuxt 等）
   - 数据库（MySQL/PostgreSQL/MongoDB/Redis 等）
   - ORM/查询构造器（Prisma/TypeORM/MyBatis/SQLAlchemy 等）

2. 识别现有安全机制
   - 是否有认证中间件（JWT/Session/OAuth）
   - 是否有限流中间件（express-rate-limit/redis-based）
   - 是否有输入验证库（zod/joi/class-validator/Pydantic）
   - 是否有 CSRF 防护、CSP 头、Helmet 等
   - 是否有文件上传库（multer/busboy/formidable）

3. 识别依赖安全模式
   - 查找现有的 sanitization / escape / parameterization 模式
   - 记录项目已采用的"安全写法"作为对比基准

> 输出：内部使用，记录项目"已知安全基线"。后续审查时遵循项目已有模式给出修复建议（避免引入项目未使用的新依赖）。

Phase 2 — 分领域审查（Domain-by-Domain Audit）

按三个维度并行审查，每个维度对应一份 checklist：

审查方法（借鉴 Anthropic 三阶段法）：
1. 上下文研究 — 用 Grep/Glob 找出该领域相关的代码（如查 SQL 拼接就 grep query\(、$query、raw\(）
2. 对比分析 — 与项目现有安全模式对比，找出偏离
3. 漏洞评估 — 追踪数据流（输入 → 敏感操作），找出可利用路径

Phase 3 — 假阳性过滤（False Positive Filtering）

对 Phase 2 发现的每条疑似风险，应用 references/false-positive-rules.md 中的规则过滤：

1. HARD EXCLUSIONS — 命中即剔除（如单元测试文件、文档文件、Rust 内存安全、环境变量可信等）
2. PRECEDENTS — 参考判例（如 React/Angular 默认安全、客户端权限检查缺失不是漏洞）
3. 信号质量标准 — 评估是否：
   - 有具体可利用漏洞和明确攻击路径
   - 代表真实安全风险 vs 理论最佳实践
   - 有具体代码位置和复现步骤
   - 对安全团队有可操作性
4. 置信度评分（0-1.0）：
   - 0.9-1.0：确定的可利用路径，已尽可能验证
   - 0.8-0.9：清晰的漏洞模式，已知利用方法
   - 0.7-0.8：可疑模式，需要特定条件触发
   - < 0.7：不报告（太投机）

最终输出：仅保留置信度 ≥ 0.7 的发现。

检查类别总览

后端风险（详见 backend-checklist.md）

• 注入类：SQL 注入、NoSQL 注入、命令注入、LDAP/XPath 注入、模板注入、ORM 拼接
• 认证授权：BOLA（越权访问对象）、BFLA（越权调用函数）、JWT 失效、会话固定、弱密码
• 加密：硬编码密钥、弱算法（MD5/DES）、不安全随机数、证书验证绕过
• SSRF：服务端请求伪造（注意：仅控制 path 不算，必须能控制 host/protocol）
• 反序列化：Java Serializable、Python pickle、YAML.load、PHP unserialize
• XXE：XML 外部实体解析
• 配置类：CORS 错配、CSP 缺失、调试模式开启、依赖漏洞
• 并发竞态（重点）：TOCTOU、库存超卖、余额竞态、重复提交、限购绕过

前端风险（详见 frontend-checklist.md）

• XSS：反射型、存储型、DOM 型、v-html、dangerouslySetInnerHTML、bypassSecurityTrustHtml
• CSRF：SameSite 缺失、Token 位置不当、无 CSRF Token
• 敏感数据存储：localStorage 存 Token/密钥、XSS 可拿 Cookie、敏感信息入 URL
• 开放重定向：用户可控的 redirect 参数未校验
• postMessage 滥用：未校验 origin、使用 * target
• 点击劫持：缺失 X-Frame-Options / CSP frame-ancestors
• 无限访问（重点）：无节流/防抖、无限轮询、循环请求、无前端速率限制、无退避重试

资源滥用风险（详见 resource-abuse.md）— 用户重点

• 服务器并发：竞态条件、非原子操作、缺锁、TOCTOU
• API Rate Limiting：无限制、无配额、无熔断、无降级
• 文件上传滥用：无类型校验、无大小限制、无数量限制、无 MIME 检查、可执行文件、目录穿越
• 慢速攻击：Slowloris 防护、慢速 POST body
• 内存/CPU 耗尽：Hash 碰撞 DoS、正则 ReDoS、大文件加载到内存
• 前端无限访问：循环请求、无指数退避、无最大重试次数

输出格式

文件位置

docs/安全审查-YYYY-MM-DD.md

• 文件名按当天日期生成；同一天多次扫描追加 -N 后缀（-2、-3）
• 若项目无 docs/ 目录，先询问用户是否创建
• 用户可指定输出路径：如「输出到 security-reports/2026-07.md」

报告结构

# 安全审查报告

**扫描日期**：2026-07-18
**扫描范围**：全项目（g:/xxx/xxx）
**技术栈**：后端 NestJS + Prisma + PostgreSQL；前端 React + Vite + Zustand
**扫描文件数**：234 个
**审查耗时**：约 12 分钟

---

## 风险等级汇总

| 等级 | 数量 | 说明 |
|------|------|------|
| 🔴 高危 | 2 | 直接可利用，需立即修复 |
| 🟡 中危 | 5 | 需特定条件触发，建议尽快修复 |
| 🟢 低危 | 3 | 纵深防御问题，择机修复 |
| ℹ️ 建议 | 1 | 最佳实践建议，非漏洞 |

---

## 详细发现

### 🔴 高危 #1：SQL 注入 — 用户搜索接口

- **位置**：`src/api/search.ts:42`
- **类别**：`sql_injection`
- **置信度**：0.95
- **风险说明**：用户输入的 `keyword` 参数直接拼接进 SQL 查询，未参数化
- **Exploit 场景**：
  攻击者构造 `?keyword='; DROP TABLE users; --` 可删除整张用户表；
  或 `?keyword=' UNION SELECT password FROM users --` 可导出所有密码哈希
- **问题代码**：
  \```ts
  // ❌ 危险：直接拼接
  const sql = `SELECT * FROM products WHERE name LIKE '%${keyword}%'`;
  const rows = await db.query(sql);
  \```
- **修复建议**：
  \```ts
  // ✅ 安全：参数化查询（遵循项目已有 Prisma 模式）
  const rows = await db.product.findMany({
    where: { name: { contains: keyword, mode: 'insensitive' } }
  });
  \```
- **修复优先级**：P0（立即）

---

### 🔴 高危 #2：库存超卖竞态 — 下单接口

- **位置**：`src/api/order.ts:88-105`
- **类别**：`race_condition`
- **置信度**：0.90
- **风险说明**：检查库存与扣减库存非原子操作，高并发下会超卖
- **Exploit 场景**：
  攻击者并发发起 100 个下单请求，由于"查库存→扣库存"非原子，
  全部请求都通过库存检查，最终扣减 100 件但库存只有 10 件，造成超卖 90 件
- **问题代码**：
  \```ts
  // ❌ 危险：先查后扣，非原子
  const stock = await db.product.findUnique({ where: { id } });
  if (stock.count < orderQty) throw new Error('库存不足');
  await db.product.update({
    where: { id },
    data: { count: { decrement: orderQty } }
  });
  \```
- **修复建议**：
  \```ts
  // ✅ 安全：原子条件更新 + 行锁
  const result = await db.product.updateMany({
    where: { id, count: { gte: orderQty } },  // 条件扣减，原子
    data: { count: { decrement: orderQty } }
  });
  if (result.count === 0) throw new Error('库存不足');
  \```
- **修复优先级**：P0（立即）

---

### 🟡 中危 #3：API 无 Rate Limiting — 登录接口

...（以此类推）

---

## 修复优先级建议

| 优先级 | 数量 | 处理时机 |
|--------|------|---------|
| P0 立即 | 2 | 阻断发布，今天修 |
| P1 本周 | 5 | 下个迭代前修完 |
| P2 本月 | 3 | 排入待办 |
| P3 建议 | 1 | 择机优化 |

---

## 已剔除的疑似风险（假阳性）

| 位置 | 类别 | 剔除原因 |
|------|------|---------|
| `tests/utils.test.ts:15` | hardcoded_secret | 单元测试文件不报 |
| `config/env.ts:8` | env_var_injection | 环境变量可信 |
| `frontend/src/App.tsx:30` | xss_missing_sanitize | React 默认转义，未用 dangerouslySetInnerHTML |

输出要求

工作量校准

与官方 security-review 的协同

• 本 skill 不替代 Anthropic 官方 /security-review 命令
• 官方擅长：注入、认证、加密、RCE、数据泄露（变更差异扫描）
• 本 skill 擅长：资源滥用、并发竞态、限流、上传滥用（全项目深度扫描）
• 推荐组合使用：
  1. 日常 PR 用官方 /security-review（快、准、变更聚焦）
  2. 定期（每月/发版前）用本 skill 做全项目安全体检

跨平台兼容性

此 skill 设计为跨 AI 平台兼容（Trae、Claude Code、WorkBuddy 等）：

• 不依赖平台特定功能，所有操作通过通用工具完成（Grep/Glob/Read/Task）
• 标准化 Markdown + YAML frontmatter
• 各平台自动适配对应工具

记住：这个 skill 的目标是发现真实可被利用的风险，不是堆理论最佳实践。宁缺毋滥。