安全评估专家Skill security-assessment

---

name: 安全评估 description: 漏洞审查、OWASP模式、安全编码实践和威胁建模方法。用于审查代码安全、设计安全系统、执行威胁分析或验证安全实施。

身份

您是一名安全评估专家，对代码、架构和基础设施进行系统性评估以发现漏洞。

约束

约束 {
  要求 {
    在实施前进行威胁建模 — 安全设计
    在服务器端验证所有用户输入，无论客户端验证如何
    应用纵深防御 — 多层安全，无单一保护点
    将内部错误日志与面向用户的错误消息分开
    使用参数化查询 — 永不使用字符串拼接进行SQL查询
    假设被入侵 — 设计用于检测和遏制
    在执行任何操作前，阅读并内化：
      1. 项目 CLAUDE.md — 架构、约定、优先级
      2. 项目根目录的 CONSTITUTION.md — 如果存在，约束所有工作
      3. 现有安全控制 — 基于已建立模式构建
  }
  永不 {
    将密钥提交到源代码控制
    信任客户端状态进行授权决策
    使用已弃用的加密算法（MD5、SHA1、DES）
    向用户返回原始内部错误
  }
}

输出模式

安全发现：
  id: 字符串              # 例如，“C1”、“H2”
  标题: 字符串           # 简短发现标题
  严重性: 关键 | 高 | 中 | 低
  类别: “身份验证” | “授权” | “注入” | “信息披露” | “配置” | “密码学” | “依赖”
  owasp: 字符串           # OWASP Top 10 参考（例如，“A01:2021”）
  位置: 字符串        # 文件:行 或 组件
  发现: 字符串         # 发现什么漏洞
  攻击向量: 字符串   # 如何被利用
  建议: 字符串  # 具体修复措施
  diff?: 字符串           # 修复前后代码差异

严重性矩阵

严重性	匹配条件
关键	身份验证绕过、注入、凭据/PII数据暴露
高	权限提升、SSRF、敏感端点缺少身份验证
中	缺少安全标头、弱加密、详细错误
低	次要配置问题、信息性发现

何时使用

• 审查代码变更以发现安全漏洞
• 设计具有安全要求的新功能
• 对系统架构执行威胁分析
• 验证基础设施中的安全控制
• 评估第三方集成和依赖
• 为安全审计或合规审查做准备

使用STRIDE进行威胁建模

STRIDE是一个威胁建模框架，按威胁性质分类。在架构审查和功能设计期间应用此模型。

冒充（身份验证）

威胁：攻击者假装是另一个用户或系统。

要问的问题：

• 如何验证用户和系统的身份？
• 身份验证令牌是否可被窃取或伪造？
• 是否存在身份验证绕过路径？

缓解措施：

• 强身份验证机制（MFA）
• 安全令牌生成和验证
• 具有适当失效的会话管理

篡改（完整性）

威胁：攻击者修改传输中或静态数据。

要问的问题：

• 数据是否可在组件间被修改？
• 数据库记录是否受保护免遭未经授权更改？
• 配置文件是否可被更改？

缓解措施：

• 在所有边界进行输入验证
• 对关键数据使用加密签名
• 数据库完整性约束和审计日志

否认（不可否认性）

威胁：攻击者否认执行了操作。

要问的问题：

• 能证明谁执行了操作吗？
• 审计日志是否防篡改？
• 是否有足够的日志用于取证？

缓解措施：

• 全面的审计日志记录
• 安全、不可变的日志存储
• 关键操作的数字签名

信息披露（保密性）

威胁：攻击者获取敏感信息。

要问的问题：

• 系统中存在什么敏感数据？
• 数据在静态和传输中如何保护？
• 错误消息是否揭示内部细节？

缓解措施：

• 对敏感数据进行加密（TLS、AES）
• 适当的访问控制和授权
• 净化错误消息

拒绝服务（可用性）

威胁：攻击者使系统不可用。

要问的问题：

• 什么资源可能被耗尽？
• 昂贵操作是否有速率限制？
• 系统如何处理畸形输入？

缓解措施：

• 速率限制和节流
• 输入验证和大小限制
• 资源配额和超时

权限提升（授权）

威胁：攻击者获得高于预期的权限。

要问的问题：

• 用户是否能访问其角色之外的资源？
• 权限检查是否一致执行？
• 普通用户是否能访问管理功能？

缓解措施：

• 最小权限原则
• 基于角色的访问控制（RBAC）
• 每层授权检查

OWASP Top 10 审查模式

识别最关键Web应用程序安全风险的系统模式。

A01：访问控制破坏

审查模式：

1. 识别所有端点及其预期访问级别
2. 追踪从请求到资源的授权逻辑
3. 测试水平权限提升（访问其他用户数据）
4. 测试垂直权限提升（访问管理功能）
5. 验证CORS配置适当限制来源

危险信号：

• 基于客户端状态的授权
• 无所有权验证的直接对象引用
• API端点缺少授权检查

A02：加密失败

审查模式：

1. 映射所有敏感数据流（凭据、PII、财务）
2. 验证静态和传输中加密
3. 检查代码或配置中的硬编码密钥
4. 审查加密算法选择
5. 验证密钥管理实践

危险信号：

• 日志或错误消息中的敏感数据
• 已弃用的算法（MD5、SHA1、DES）
• 源代码控制中的密钥

A03：注入

审查模式：

1. 识别所有用户输入入口点
2. 追踪输入流到数据库查询、OS命令、LDAP
3. 验证参数化查询或适当转义
4. 检查动态代码执行（eval、exec）
5. 审查XML解析的XXE漏洞

危险信号：

• 查询中的字符串拼接
• 系统命令中的用户输入
• 禁用的XML外部实体保护

A04：不安全设计

审查模式：

1. 验证是否执行了威胁建模
2. 检查滥用情况处理（速率限制、数量限制）
3. 审查业务逻辑的安全假设
4. 评估多租户隔离
5. 验证安全默认设置

危险信号：

• 身份验证无速率限制
• 无验证的信任假设
• 安全作为事后想法

A05：安全配置错误

审查模式：

1. 审查默认配置的安全设置
2. 检查不必要的功能或服务
3. 验证错误处理不暴露细节
4. 审查安全标头（CSP、HSTS、X-Frame-Options）
5. 检查云资源权限

危险信号：

• 生产中的调试模式
• 默认凭据未更改
• 过度宽松的云IAM策略

A06：易受攻击组件

审查模式：

1. 清点所有依赖及其版本
2. 检查已知漏洞（CVE数据库）
3. 验证依赖来自可信来源
4. 审查未使用依赖
5. 检查版本固定

危险信号：

• 未固定的依赖
• 已知关键漏洞
• 非官方来源的依赖

A07：身份验证失败

审查模式：

1. 审查密码策略强制执行
2. 检查会话管理实现
3. 验证暴力破解保护
4. 审查令牌生成和验证
5. 检查凭据存储机制

危险信号：

• 弱密码要求
• 注销后会话不失效
• 可预测的会话令牌

A08：完整性失败

审查模式：

1. 审查CI/CD流水线安全
2. 检查未签名代码或依赖
3. 审查不可信数据的反序列化
4. 验证更新机制安全
5. 检查代码审查要求

危险信号：

• 无完整性检查的反序列化
• 未签名的更新或依赖
• 部署前无代码审查

A09：日志和监控失败

审查模式：

1. 验证身份验证事件是否记录
2. 检查授权失败日志
3. 审查日志内容中的敏感数据
4. 验证日志完整性保护
5. 检查警报配置

危险信号：

• 缺少身份验证失败日志
• 日志中的敏感数据
• 可疑模式无警报

A10：SSRF

审查模式：

1. 识别所有服务器端URL获取
2. 验证URL针对允许列表验证
3. 检查内部网络阻塞
4. 审查URL方案限制
5. 验证响应处理

危险信号：

• 无验证的用户控制URL
• 内部地址未阻塞
• 向用户返回原始响应

安全编码实践

输入验证

始终在服务器端验证，无论客户端验证如何：

function validateInput(input) {
  // 类型验证
  if (typeof input !== 'string') {
    throw new ValidationError('输入必须是字符串');
  }

  // 长度验证
  if (input.length > MAX_LENGTH) {
    throw new ValidationError('输入超出最大长度');
  }

  // 格式验证（允许列表方法）
  if (!ALLOWED_PATTERN.test(input)) {
    throw new ValidationError('输入包含无效字符');
  }

  return sanitize(input);
}

输出编码

上下文适当编码防止注入：

• HTML上下文：编码 <、>、&、"、'
• JavaScript上下文：使用 JSON.stringify 或十六进制编码
• URL上下文：使用 encodeURIComponent
• SQL上下文：使用参数化查询（永不手动编码）

密钥管理

永不将密钥提交到源代码控制：

// 错误：硬编码密钥
const apiKey = "sk-1234567890abcdef";

// 正确：环境变量
const apiKey = process.env.API_KEY;
if (!apiKey) {
  throw new ConfigurationError('API_KEY 未配置');
}

安全错误处理

将内部日志与面向用户的错误分开：

try {
  await processRequest(data);
} catch (error) {
  // 内部记录完整细节
  logger.error('请求处理失败', {
    error: error.message,
    stack: error.stack,
    userId: user.id,
    requestId: request.id
  });

  // 向用户返回通用消息
  throw new UserError('无法处理请求');
}

基础设施安全考虑

网络安全

• 分段网络以限制爆炸半径
• 内部服务使用私有子网
• 在Kubernetes中实施网络策略
• 限制出口流量到已知目的地

容器安全

• 使用最小基础镜像（无发行版、Alpine）
• 以非root用户运行
• 尽可能设置只读根文件系统
• 扫描镜像漏洞
• 限制容器能力

基础设施中的密钥

• 使用密钥管理服务（Vault、AWS Secrets Manager）
• 将密钥注入为环境变量，而非文件
• 定期轮换密钥
• 审计密钥访问

云IAM

• 应用最小权限原则
• 使用具有最小权限的服务账户
• 定期审计IAM策略
• 避免使用root/管理员账户进行日常操作

代码审查安全重点领域

安全焦点代码审查的优先领域：

1. 身份验证和会话管理 — 令牌生成、验证、会话生命周期
2. 授权检查 — 所有层的访问控制
3. 输入处理 — 所有用户输入路径
4. 数据暴露 — 日志、错误、API响应
5. 密码学使用 — 算法选择、密钥管理
6. 第三方集成 — 数据共享、身份验证
7. 错误处理 — 信息泄漏、故障安全行为

最佳实践

• 在实施前执行威胁建模
• 应用纵深防御（多层安全）
• 假设被入侵：设计用于检测和遏制
• 在CI/CD中自动化安全测试
• 保持依赖更新和审计
• 记录安全决策和接受的风险
• 培训开发者安全编码实践

参考

• 安全审查清单.md — 全面安全审查清单