mcpField
C
competition-template-render-path

competition-template-render-path

github.com/zhaoxuya520安全43.7k94 次安装5 周前更新
代码仓库

关于 competition-template-render-path

用于 CTF 安全分析的技能,追踪路由解析、服务端渲染上下文、模板与 hydration 的行为。它适用于关键问题位于渲染路径的场景,并须在 `$ctf-sandbox-orchestrator` 建立沙箱上下文后使用。

主要功能

  1. 01梳理路由到渲染的流程
  2. 02追踪加载器、模板与 hydration 数据
  3. 03比较渲染门控和处理器校验
  4. 04缩减为最小渲染路径
  5. 05保留路由与 hydration 证据

适用场景

  1. 01调查渲染层与处理器层的访问校验差异
  2. 02追踪 HTML 或 hydration 数据中的隐藏内容
  3. 03复现特定路由的渲染分支

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/zhaoxuya520/reverse-skill --skill competition-template-render-path

安装后在 Claude Code 中输入/competition-template-render-path确认已加载。

附带文件agents/openai.yamlreferences/template-render-path.md

详细介绍

竞赛模板渲染路径

仅当 $ctf-sandbox-orchestrator 已处于活动状态,并且已经建立沙箱假设、节点归属和证据优先级之后,才将此技能用作下游专门化技能。如果尚未做到这一点,请先回到 $ctf-sandbox-orchestrator。

当决定性的 bug 或产物存在于路由解析、服务端渲染上下文、模板数据或 hydration 交接中,而不仅仅存在于普通 JSON API 中时,请使用此技能。

除非用户明确要求英语,否则请用简体中文回复。

快速开始

  1. 按顺序梳理渲染链:路由解析、loader 或数据获取、模板或组件上下文、响应 HTML、hydration 载荷以及客户端接管。
  2. 在改动任何内容之前,记录 host、路由参数、预览开关、租户或 host 切换,以及仅服务端变量。
  3. 比较模板门控与 loader 或 handler 强制执行。
  4. 保留一条成功渲染路径和一条失败渲染路径,并保持最小差异。
  5. 复现能够证明决定性行为的最小请求到渲染分支。

工作流

1. 将路由映射到渲染上下文
  • 记录当前视图的 host、路径、路由匹配、loader、模板、布局、hydration blob 和客户端启动 chunk。
  • 注明响应是 SSR HTML、静态 HTML 加 hydration、边缘渲染内容,还是由另一条路由使用的模板片段。
  • 将仅服务端上下文与客户端可见上下文分开保存。
2. 追踪模板与强制执行边界
  • 显示权限、功能标志、预览状态、租户选择或基于 host 的开关是在哪里应用的。
  • 比较模板级门控、loader 级门控和后端 handler 强制执行,而不是信任任何单一层。
  • 记录暴露决定性分支的隐藏字段、内联数据、hydration JSON、meta 标签或替代 partial。
3. 缩减到决定性渲染路径
  • 将结果压缩为最小序列:请求 -> 路由匹配 -> loader 或模板上下文 -> 渲染输出或隐藏数据 -> 最终效果。
  • 清楚说明决定性弱点存在于路由选择、模板上下文构造、服务端-客户端 hydration 交接,还是渲染与 handler 之间的强制执行不一致。
  • 如果任务主要变为恢复生成的 bundle 或重建 source map,请移交给更专门的 bundle 技能。

阅读此参考

  • 加载 references/template-render-path.md 以获取渲染检查清单、hydration 检查清单和证据打包。

需要保留的内容

  • 路由名称、loader 名称、模板、布局、hydration 键,以及 host 或预览开关
  • 一组成功或失败对照,用于显示渲染层行为在哪里发生分歧
  • 一条到达决定性分支的最小请求到渲染序列

评论

支持 Markdown