turtle-harden

海龟加固 🐢

海龟从不急躁。它带着古老的耐心穿行于森林地面，仔细检查每一条树根、每一块石头、每一片阴影。它的壳并非后来钉上的盔甲，而是与脊椎融合的骨骼、层层覆盖在甲板上的角蛋白，是从体内生长出的三层防御。这就是安全设计的含义：防护本身就是系统的一部分，而不是发布前才加上的东西。浣熊会在一片狼藉后四处翻找，蜘蛛会在门口编织锁网，而海龟确保脚下的地面本身安全可靠。纵深防御。每一层。每一次。

何时启用

• 用户说“加固这个”“让它安全”或“进行安全审查”
• 用户调用 /turtle-harden，或提到海龟／加固
• 构建新功能，并希望从设计之初就确保安全
• 将任何内容部署到生产环境之前
• 审查现有代码，查找深层或隐蔽的漏洞
• 浣熊发现了表面问题，而你想进一步深入
• 实现身份验证后（蜘蛛已织好网，现在加固其他所有部分）
• 用户说“纵深防御”或“安全设计”
• 处理任何涉及用户输入、文件上传或敏感数据的内容时
• 审查与外部服务交互的代码（存在 SSRF 风险）
• 任何多租户边界相关工作

**重要：**海龟天性细致周全。不要跳过阶段，也不要急于求成。有缺口的壳毫无防护作用。

**搭配使用：**先用 raccoon-audit 扫描机密信息，用 spider-weave 实现身份验证，用 beaver-build 编写安全回归测试

---

加固流程

WITHDRAW --> LAYER --> FORTIFY --> SIEGE --> SEAL
    |           |         |          |         |
  Survey      Build     Harden     Attack    Lock
  Attack     Found-     Deep       Test      Down &
  Surface    ation     Defense    Defenses   Report

阶段 1：缩入壳中

海龟缩进壳里，目光警觉，在安全处观察周围的世界……

加固任何内容之前，先弄清楚你要保护什么，以及它面临哪些威胁。

• 明确范围：新代码（安全设计）还是现有代码（审计）？适用哪种威胁模型？
• 梳理所有数据进入系统的入口点（URL 参数、表单、请求头、Cookie、文件、WebSocket、API、Webhook）
• 梳理所有数据离开系统的出口点（HTML、JSON、数据库写入、外部调用、日志、重定向）
• 追踪敏感数据的流向：凭据、个人身份信息、令牌、支付信息——数据从何处进入、在哪里存储、如何流转与展示，以及何时被销毁
• 评估特定技术风险：SvelteKit 布局绕过、CF Workers 机密存储、JS 中的原型污染、D1 租户隔离

**输出：**完整的攻击面图，包含入口点、出口点、数据流和特定技术风险

**深入参考：**加载 references/attack-surface.md，查看完整的入口点／出口点检查清单、数据流目录和技术栈风险模式

---

阶段 2：LAYER

一层又一层，外壳愈发坚固。骨上覆以角蛋白，脊柱之上再覆以骨骼……

应用基础防御。这些不可妥协——每段代码都必须具备这些防护层。

• 2A. 输入验证 — 在服务端验证所有入口，使用 Zod/Valibot 进行允许列表验证，并设置严格类型、长度和范围限制；拒绝无效输入，绝不静默强制转换
• 2B. 输出编码 — 在每个出口点根据上下文进行编码（HTML、JS、URL、CSS、JSON）；绝不对未经净化的输入使用 {@html}；富文本使用 DOMPurify
• 2C. 参数化查询 — SQL 中禁止字符串拼接；所有查询都使用 .bind()；使用来自 database.ts 的类型化辅助函数；使用 Promise.all() 并行查询
• 2D. 类型安全 — 在所有信任边界处必须使用 Rootwork 工具。表单数据使用 parseFormData()，KV/JSON 读取使用 safeJsonParse()，catch 代码块使用 isRedirect()/isHttpError()。信任边界处不得使用 as 类型断言。TypeScript 严格模式是基本要求；Rootwork 才是保障。参考：AgentUsage/rootwork_type_safety.md
• 2E. 错误处理 — 每个错误都使用 Signpost 代码；服务端错误使用 logGroveError()；仅向用户显示通用消息；不得泄露可用于枚举的信息；不得吞掉异常

输出： 在所有入口点和出口点应用基础防御

深入参考： 加载 references/foundational-defenses.md，查看所有五个基础防御层的完整检查清单、代码示例和 SvelteKit 模式

---

阶段 3：FORTIFY

外壳的每块甲片都与下一块紧密扣合。没有空隙，没有接缝，无路可入……

在所有安全领域应用深入的分层加固措施。

• 3A–3B. HTTP 标头与 CSP — 每个响应都必须包含安全标头；采用严格的基于 nonce 的 CSP；移除会泄露框架信息的标头
• 3C. CORS — 精确验证允许列表；绝不原样反射来源；携带凭据时绝不使用 *
• 3D–3E. 会话与 CSRF — 使用 CSPRNG 生成会话 ID；Cookie 设置 HttpOnly/Secure/SameSite；身份验证后重新生成会话；所有会更改状态的请求都必须包含 CSRF 令牌
• 3F. 速率限制 — 对身份验证和重置端点实施速率限制；设置 Cloudflare 边缘规则；在执行高开销操作前应用限制
• 3G–3H. 身份验证与授权 — 使用 Argon2id 哈希；禁止枚举；采用 PKCE OAuth；使用显式算法验证 JWT；在 hooks.server.ts 中强制执行授权，而不是在布局中；默认拒绝
• 3I. 多租户隔离 — 在请求边界处解析租户上下文；每个查询都必须通过 WHERE tenant_id = ? 限定范围；缓存键必须包含租户 ID
• 3J. 文件上传 — 使用类型允许列表并检查魔数；由服务器生成文件名；存储在 Web 根目录之外；提供文件时设置 Content-Disposition: attachment
• 3K. 数据保护 — 使用 TLS 1.2+；启用 HSTS；将机密信息存储在 Workers Secrets 中，而不是源代码中；尽量减少 PII；对令牌进行恒定时间比较

输出： 在所有安全领域应用深入的分层防御

深入参考： 加载 references/deep-defenses.md，查看全部十一项 FORTIFY 子部分（3A–3K）的完整检查清单和代码示例

阶段 4：SIEGE

测试外壳。冲击它。推动它。尝试每个角度。经受住考验的才值得信赖。发现漏洞，就能赶在敌人之前修复……

像攻击者一样思考。检查那些容易逃过常规审查的细微、罕见漏洞。

• 逐一检查下方列出的全部 19 类罕见攻击向量
• 对每一类，在脑中（或在安全的情况下实际）尝试攻击，并验证防御是否有效
• 根据是否存在相应攻击面，将每一类标记为 CLEAR、FOUND 或 N/A

要检查的攻击向量： 4A 原型污染 · 4B 时序侧信道 · 4C 竞态条件（TOCTOU）· 4D ReDoS · 4E SSRF · 4F CRLF 注入 · 4G Unicode 攻击 · 4H 反序列化 · 4I postMessage · 4J WebSocket · 4K CSS 注入 · 4L SVG XSS · 4M 缓存投毒 · 4N 开放重定向 · 4O HTTP 方法篡改 · 4P 二阶漏洞 · 4Q 供应链 · 4R Service Worker · 4S DNS 与基础设施

输出： 已测试全部罕见攻击向量，已识别漏洞或确认不存在漏洞

深入参考： 加载 references/exotic-vectors.md，查看全部 19 类攻击向量的完整检查清单和代码示例

---

阶段 5：SEAL

外壳已完成。每处缺口都已封堵。每块甲片都已对齐。乌龟坚韧不拔……

最终验证和报告。

• 纵深防御合规性——验证安全防护已分层部署：网络、应用、数据、基础设施和流程层均有覆盖；每项关键功能都有 2 项或更多独立控制措施
• 日志记录与监控——记录身份验证事件、授权失败和验证拒绝；日志不包含机密信息或个人身份信息；已配置针对暴力破解和异常行为的告警
• 构建验证（强制）——运行 pnpm install && gw ci --affected --fail-fast --diagnose；封板前修复所有回归问题
• 安全扫描——搜索硬编码机密信息、危险模式（eval、innerHTML、__proto__）和已禁用的安全防护；运行 pnpm audit
• 加固报告——生成完整的结构化报告，包含范围、防御层、罕见攻击向量结果、发现的漏洞和建议

输出： 包含纵深防御验证的完整加固报告

深入参考： 加载 references/verification-report.md，查看纵深防御表、日志检查清单、构建命令、安全扫描模式和完整报告模板

---

参考资料路由表

阶段	参考资料	加载时机
WITHDRAW	references/attack-surface.md	始终加载（加固开始时）
LAYER	references/foundational-defenses.md	始终加载（核心防御不可妥协）
FORTIFY	references/deep-defenses.md	加固 HTTP/身份验证/会话/多租户时
SIEGE	references/exotic-vectors.md	测试高级/罕见攻击向量时
SEAL	references/verification-report.md	撰写最终报告时

---

乌龟准则

耐心

乌龟从不匆忙。检查每一层。验证每一项防御。存在缺口的外壳毫无保护作用。如果某个阶段进行得太快，那就是你遗漏了某些内容。

分层

一种防御还不够。两种更好。三种才是乌龟之道。对于每项关键功能，都要验证有多项独立控制措施能够阻止同一种攻击。即使有任何单一层失效，系统仍必须安全。

安全设计

防御不是你后来添加的东西，而是你本身。当审查新代码时，问题不该是“我们应该额外加上什么安全措施？”，而应是“安全是否与生俱来地融入设计？”外壳由内而生。

重视彻底，而非速度

乌龟赢得比赛。阶段 4 中的每一种罕见攻击向量都存在，正是因为有人以为“这种事不可能发生在这里”。无论如何都要检查。看似不可能的攻击，往往最容易得手。

沟通方式

使用外壳比喻：

• “暂退一步，勘察地形……”（调查攻击面）
• “夯实基础……”（应用基础防御）
• “加固甲片……”（深入强化）
• “抵御围攻测试……”（对抗性测试）
• “封好外壳……”（最终验证）
• “外壳坚不可摧。”（强化完成）

---

反模式

乌龟绝不会：

• 因为“只是个小改动”就跳过阶段（小改动也会造成大漏洞）
• 认为来自“可信”来源的任何输入都是安全的（不信任任何内容）
• 只在边界处实施安全防护（深度防御意味着每一层都要防护）
• 把安全标头当作可选项（“以后再加”就意味着永远不加）
• 忽视罕见攻击，因为“那不太可能发生”（攻击者最喜欢出其不意）
• 在可以使用允许列表时使用阻止列表（阻止列表总有遗漏）
• 等功能“完成”后才补上安全措施（要么安全设计，要么什么都不做）
• 重复浣熊的工作（密钥扫描是浣熊的工作——乌龟负责强化）
• 草草完成 SIEGE 阶段（对抗性思维需要耐心）

---

强化示例

用户：“上线前强化博客文章创建端点”

乌龟流程：

1. 🐢 WITHDRAW — “正在勘察地形……文章创建端点通过表单操作接收标题、内容、别名和可选的图片上传。数据流：用户输入 -> 表单操作 -> D1 数据库 -> 渲染后的 HTML。攻击面：内容中的 XSS、查询中的 SQLi、内容包含用于嵌入的 URL 时可能出现 SSRF，以及图片上传中的路径遍历。”

2. 🐢 LAYER — “正在夯实基础……为所有输入添加 Zod 架构验证。标题：最多 200 个字符，去除首尾空格。内容：最多 50k，存储前使用 DOMPurify 清理。别名：仅允许字母数字字符和连字符。图片：类型采用允许列表，限制文件大小。所有查询均使用参数化查询。错误响应保持通用。”

3. 🐢 FORTIFY — “正在加固甲片……配置带随机数的 CSP。设置安全标头。通过 SvelteKit 表单操作验证 CSRF 令牌。速率限制：每个租户每小时最多 10 篇文章。在 hooks.server.ts 中验证会话。验证租户隔离——查询限定在已认证的租户范围内。图片上传：重命名后使用租户前缀存储到 R2，并通过 Content-Disposition: attachment 提供。”

4. 🐢 SIEGE — “正在抵御围攻测试……原型污染：表单数据经过 Zod 处理，安全。ReDoS：别名正则表达式简单且不回溯，安全。SSRF：此端点不会获取 URL，不适用。Unicode：别名仅限 ASCII，标题和内容在规范化后进行清理。竞态条件：文章创建按别名+租户实现幂等，安全。图片上传中的 SVG：通过 DOMPurify 清理，并由独立的 R2 域名提供。二阶 XSS：存储前和输出时都会清理内容，双重防护。”

5. 🐢 SEAL — “正在封好外壳……深度防御已验证：通过清理 + CSP + 输出编码防止 XSS（3 层）。通过参数化查询 + 输入验证防止 SQLi（2 层）。通过会话 + 租户范围限制 + CSRF 防止身份验证绕过（3 层）。5 层防御全部到位。外壳坚不可摧。”

快速决策指南

情况	方案
构建新功能	完整的 WITHDRAW->SEAL 流程，采用安全优先模式
审查现有代码	完整流程，审计模式——记录缺失项
快速安全检查	至少执行：LAYER（输入/输出/查询）+ FORTIFY（标头/CORS/CSRF）
Spider 完成身份验证编织后	FORTIFY 阶段 3D-3H（会话、身份验证、授权强化）
Raccoon 发现问题后	SIEGE 阶段——比 Raccoon 检查得更深入
多租户边界工作	重点：FORTIFY 3I + SIEGE 4C（竞态条件）+ 4P（二阶问题）
文件上传功能	重点：FORTIFY 3J + SIEGE 4L（SVG XSS）+ 4E（SSRF）
API 端点	重点：LAYER + FORTIFY 3A-3F + SIEGE 4O（HTTP 方法篡改）
生产环境部署前	完整流程，验证纵深防御合规性

---

第 2 阶段（LAYER）检查清单

• 所有表单数据都使用带有 Zod schema 的 parseFormData()
• 所有 KV/JSON 读取都使用带有 Zod schema 的 safeJsonParse()
• 所有 SvelteKit catch 块都使用 isRedirect()/isHttpError()
• 信任边界处没有 as 类型断言
• Schema 定义在模块作用域，而不是处理程序内部

---

与其他技能的集成

强化前：

• bloodhound-scout — 强化前先了解代码库
• eagle-architect — 用于安全架构决策
• raccoon-audit — 先让 Raccoon 找出机密信息，再由 Turtle 加固

强化期间：

• spider-weave — 如果需要实现身份验证（而不只是强化）
• elephant-build — 如果强化需要修改多个文件
• beaver-build — 在强化的同时编写安全回归测试

强化后：

• raccoon-audit — 最后全面检查，查找任何遗漏
• fox-optimize — 如果速率限制或安全检查影响性能
• owl-archive — 记录安全架构

---

外壳由内而生。防御不是你添加的东西，而是你自身的一部分。 🐢