security-hardening

用途：该技能用于在已有安全发现（来自代码审计或渗透测试）时，正确地按照安全编码模式进行修复，并验证修复确实关闭了漏洞。定位为修复阶段，把发现转化为正确、可验证的修复。\n\n核心原则：未重新测试的修复只是期望，而非修复。需重现原始利用并确认其现已失败。\n\n每项发现的处理流程：1. 根因——为何不受信任的数据到达了汇聚点，从那里修复，而非用黑名单屏蔽症状。2. 套用安全模式（见对照表）。3. 纵深防御——增加第二道独立控制（如验证+参数化）。4. 重新测试——重跑来自主动渗透/审计的同一 PoC，确认现已失败。5. 回归——添加测试以防悄然复发。\n\n安全模式快速参考（漏洞→根因修复→纵深防御）：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+加密→证书固定、二进制中无秘密。\n\n验证准则：在服务端验证，客户端验证只是 UX 而非安全；白名单优于黑名单；为汇聚点编码而非源头编码；故障关闭，默认拒绝，错误不应授予访问。\n\n重新测试门禁：重跑原始 PoC→现失败/被阻止；添加自动化回归测试；检查修复未把汇聚点移到别处；验证没有类似实例存在（跨代码库 grep 该模式）。\n\n输出：对每项发现给出根因、修复（diff/模式）、重新测试结果（PoC 现失败）、已添加的回归测试，并把发现登记表状态更新为已关闭。\n\n常见错误：只修补被报告的那一行而其他地方仍有相同汇聚点；可被攻击者轻易绕过的黑名单过滤器；仅客户端修复服务端问题；未重跑利用就标记为已修复。\n\n限制：资料为通用修复流程与模式参考，未提供具体代码示例、平台、价格或安装命令；实际适用性取决于具体项目与发现类型。