security-hardening

安全加固（FIX 阶段）

概述

将发现的问题转化为正确且经过验证的修复。在恰当的层级修复根本原因，增加 纵深防御，然后重新测试，证明漏洞已封堵。

核心原则： 未经重新测试的修复只是寄望，不算修复。重现原始攻击，并确认现在会失败。

针对每项发现的流程

1. 根本原因——为何不可信数据会到达危险点？在根源处修复，而不是通过封锁表面症状来处理。
2. 采用安全模式——参见下表。
3. 纵深防御——增加第二道独立控制（例如验证 + 参数化）。
4. 重新测试——重新运行 active-pentest/审计中的精确 PoC；确认现在会失败。
5. 回归测试——添加测试，防止问题悄然复发。

安全模式速查表

漏洞	根本原因修复	纵深防御
SQL/NoSQL 注入	使用参数化查询 / ORM 绑定；动态标识符采用允许列表	数据库用户遵循最小权限原则；输入验证
命令注入	避免使用 shell；使用 exec 数组 / 安全 API；不进行 shell 插值	参数采用允许列表；降低权限
XSS	根据上下文进行输出编码；使用框架自动转义；使用 textContent	CSP；清理 HTML（DOMPurify）；使用 HttpOnly Cookie
访问控制失效 / IDOR	在服务端对每项操作执行授权；将查询范围限制为当前用户	默认拒绝；集中式策略检查
批量赋值	明确列出可绑定字段（DTO/schema）	分离读写模型
身份验证失效	使用 bcrypt/argon2；使用 CSPRNG 令牌；登录时轮换会话	MFA；速率限制；缩短令牌 TTL 并支持撤销
加密失效	使用经过审查的库；使用 AES-GCM；全程使用 TLS；不自制加密方案	密钥管理/轮换；HSTS
SSRF	使用目标允许列表；解析并验证；阻止访问元数据/内部 IP	出站防火墙；不直接获取原始 URL
不安全的反序列化	使用安全格式（JSON）；使用 yaml.safe_load；签名载荷	类型允许列表；隔离
代码中包含密钥	移至环境变量/密钥管理器；轮换已暴露的密钥	在 CI 中扫描密钥；使用短期令牌
安全配置错误	禁用调试；采用最小权限 CORS；移除默认凭据	加固基线；在 CI 中审查配置
移动端存储不安全	使用 Keychain/Keystore 并加密	固定证书；二进制文件中不包含密钥

验证经验法则

• 在服务端验证——客户端验证只改善用户体验，不提供安全保障。
• 允许列表优于阻止列表——明确允许的内容，拒绝其余所有内容。
• 根据危险点而非数据源进行编码——相同的数据在不同上下文中需要不同的编码。
• 默认拒绝——默认拒绝访问；错误不应导致授权。

重新测试关卡（切勿跳过）

[ ] Re-ran the original PoC → it now fails / is blocked
[ ] Added an automated regression test
[ ] Checked the fix didn't just move the sink elsewhere
[ ] Verified no similar instances exist (grep the pattern across the codebase)

输出

针对每项发现：根本原因 · 修复方案（差异/模式）· 重新测试结果（PoC 现在会失败）· 已添加回归测试。将发现问题登记表中的状态更新为 → 已关闭。

常见错误

• 只修补报告中的那一行，却未处理其他位置的相同危险点——搜索相似代码。
• 使用阻止列表过滤器（例如移除 <script>），攻击者很容易绕过。
• 只在客户端修复服务端问题。
• 未重新运行攻击就标记为“已修复”。