security-check

安全检查

硬性门槛：凭据处理

CREDENTIAL HANDLING (W007 — Insecure Credential Exposure Defense):
- NEVER reproduce credentials, tokens, API keys, passwords, or secrets verbatim
  in output — flag by file path and line number only.
- When a finding involves secrets in code or logs, report:
    Affected file: app/config/initializers/foo.rb:12
    Finding: API key present in plain text — move to Rails credentials or ENV
  Do NOT quote the secret value itself.
- Exploitability Verification sub-sections MUST use generic placeholder values
  (e.g. "<REDACTED>", "<TOKEN>") — never the actual credential.
- If a file scan returns a secret value, stop — report its location, not its content.

快速参考

领域	关键检查点
认证	每个敏感操作都要有权限控制
参数	禁止 permit!，仅允许安全属性白名单
查询	使用参数化 — 禁止在 SQL 中做字符串插值
重定向	限制为相对路径或白名单
输出	禁止对用户内容使用 html_safe/raw
机密	凭据加密存储，绝不写入代码或日志
文件	校验文件名、内容类型、目标位置

核心流程

核心原则： 优先处理可被利用的问题，而非风格问题。将所有不可信输入视为可能被滥用。

0. 检查工作区

在编写任何发现或分析之前，你必须运行搜索和目录列举工具来查找工作区中的源文件（例如控制器、模型、配置文件）。对实际找到的文件执行代码级安全审查。仅当工作区完全为空时，才可以返回一份检查清单并说明未提供任何源文件。

审查顺序

按以下顺序进行审查，并按相同顺序输出各章节：

1. 认证与授权边界。
2. 参数处理与敏感属性赋值。
3. 重定向、渲染与输出编码。
4. 文件处理、网络调用与后台任务输入。
5. 机密、日志记录与运维暴露。
6. 验证每项发现： 在报告前，用具体攻击场景确认其可被利用。排除误报（例如对开发者定义的常量而非用户输入使用 html_safe）。

验证门槛： 第一个输出章节必须始终是“认证与授权”。如果不存在认证/授权问题，请在任何其他类别之前以“认证与授权：未发现问题”开头。

严重级别

高

• 授权缺失/可绕过 — 未受保护的敏感操作
• 注入 — 通过用户输入进行 SQL、shell、YAML 或常量注入
• 不安全重定向 / SSRF — 由用户控制的值驱动的出站请求或重定向
• 盲目信任文件上传 — 文件名、内容类型或目标位置未经验证
• 代码/日志中的机密 — 令牌或凭据被提交或打印

中

• 参数过滤薄弱 — permit! 或未限定范围的大规模赋值
• 未消毒的 HTML 输出 — 用户控制的内容未经消毒即渲染
• 明文敏感日志 — 日志语句中包含 PII 或凭据
• 隐藏的安全行为 — 认证逻辑埋藏在回调或任务中且无护栏
• 脆弱的自定义认证 — 重新实现框架原语已安全提供的功能

示例

高严重级别（未限定范围的重定向）：

# Bad: user-controlled redirect — open redirect / phishing risk
redirect_to params[:return_to]

# Good: relative path only
redirect_to root_path
# Good: allowlist
SAFE_PATHS = %w[/dashboard /settings].freeze
redirect_to(SAFE_PATHS.include?(params[:return_to]) ? params[:return_to] : root_path)

中严重级别（大规模赋值）：

# Bad: privilege escalation risk
params.require(:user).permit!

# Good: explicit allowlist — never include role, admin, or privilege fields
params.require(:user).permit(:name, :email)

输出风格

当被要求执行安全审计时，你的输出必须包含：

1. 章节顺序 — 按指定的精确顺序，每个审查领域对应一个章节；对空章节写“未发现问题”，并注明验证该类别需要哪些证据
2. 发现详情 — 每项发现包含：
   • 严重级别： 高或中（不要用“严重”）
   • 攻击路径： 输入 → 到达 → 影响
   • 受影响文件： 路径 + 行号，例如 app/controllers/documents_controller.rb:42
   • 缓解措施： 最小可行的修复
   • 假设性可利用性验证 子章节：用具体示例漏洞和利用请求/载荷证明其可利用性。此子章节属于验证步骤与质量门槛内部，绝不作为顶层章节。
3. 不得暗示路径 — 当未分析任何源代码时，使用通用占位符，如 SRC_DIR/ 或 HYPOTHETICAL_DIR/hypothetical_controller.rb
4. 语言 — 必须使用英语，除非明确要求使用其他语言

扩展资源（渐进式披露）

仅在需要其特定内容时才加载这些文件：

• PITFALLS.md — 当你需要常见安全陷阱和误报的详细示例以避免时使用

集成

技能	何时串联
code-review	用于包含非安全问题的完整代码审查
review-architecture	当安全问题源于架构问题时
review-migration	审查迁移安全性（数据暴露、约束）时
security-review-process （来自 ruby-core-skills）	流程规范：OWASP 检查清单、Ruby 层面的安全问题