企业官网建设流程全解析

• 网络安全
• 应用安全
• 渗透测试

本文以仓库Client Side Path Traversal/README.md为主体，系统讲解客户端路径遍历（Client-Side Path Traversal，CSPT）的成因、与fetch归一化机制的关系，以及两条最核心的利用链——CSPT to XSS与CSPT to CSRF（CSPT2CSRF）。读完本文，你将能够独立识别 CSPT 漏洞点、构造../注入 payload、理解 CSPT 为何能绕过 anti-CSRF token 与 SameSite=Lax 防护，并掌握对应的检测工具与实验环境。

什么是 Client-Side Path Traversal（CSPT）

CSPT（Client-Side Path Traversal，客户端路径遍历）有时也被称为"On-site Request Forgery"（站内请求伪造），是一种可以被用作 CSRF 或 XSS 攻击跳板/工具的漏洞。它与传统的服务端路径遍历（见仓库中 Directory Traversal/README.md）最大的区别在于：问题发生在浏览器前端的 JavaScript 代码中，而不是服务端的文件系统访问逻辑中。

CSPT 的核心成因可以概括为三点：

1. 客户端发起请求：页面内的 JavaScript 使用fetch（或其他请求 API）向某个 URL 发起请求，而这个 URL 的路径部分拼接了攻击者可控且未正确编码的输入。
2. ../序列注入：攻击者在可控输入中注入多个../字符，经过 URL 路径**归一化（normalization）**后，这些字符会把请求“重定向”到一个完全不同的 URL（端点），从而可能导致安全破坏。
3. 浏览器自动携带凭据：由于每次请求都是从应用前端内部发起的，浏览器会自动附带 Cookie 以及其他认证机制，使得这些请求天然具备“已登录用户”的上下文，可供攻击利用。

从本质上看，CSPT 利用了“服务端/浏览器对路径的归一化行为”与“开发者对前端 URL 拼接逻辑的信任”之间的落差：开发者以为输入只会作为路径片段的一部分，而归一化规则却允许..跳出当前路径层级。

攻击前提与原理：为什么../能改变请求去向

一个存在 CSPT 的典型场景如下：

• 页面https://example.com/static/cms/news.html接收参数newsitemid；
• 页面 JavaScript 随后执行类似fetch('/newitems/' + newsitemid)的操作去拉取新闻内容；
• 攻击者把newsitemid设为../pricing/default.js?cb=...之类的值；
• 浏览器在发起请求前会对 URL 做归一化：/newitems/../pricing/default.js被解析为/pricing/default.js，于是请求被发送到了攻击者指定的端点。

值得强调的是，这类“输入未编码就拼进路径”的问题在很多 SPA（单页应用）中普遍存在——前端为了复用后端渲染的内容或跨模块获取数据，经常用字符串模板拼接 URL。可参考仓库 XSS Injection/README.md 中对 DOM 型 XSS 的描述：客户端对输入的处理缺陷同样是漏洞面的一部分，只是 CSPT 的落点在“请求路径”而非“DOM 渲染”。

Methodology：CSPT 的两条主要利用链

CSPT to XSS

CSPT 可以被链式利用升级为 XSS。攻击者在发现一个可控的路径片段后，可以把它指向前端页面中另一个存在文本注入（text injection）的 JS 或 HTML 端点，让原本只能控制请求 URL 的攻击变成可执行脚本的攻击。

原文档给出的经典示例链路如下：

• 页面https://example.com/static/cms/news.html接收参数newsitemid；
• 它会去fetch内容：https://example.com/newitems/<newsitemid>；
• 同时，研究者发现https://example.com/pricing/default.js中存在一个可通过cb参数触发的文本注入点；
• 最终 payload：

https://example.com/static/cms/news.html?newsitemid=../pricing/default.js?cb=alert(document.domain)//

这条链的巧妙之处在于：

• newsitemid=../pricing/default.js经过归一化后，把请求从/newitems/...跳转到/pricing/default.js；
• 第二个?使得cb参数能够传入 JS 端点；alert(document.domain)是注入到响应内容中的 JavaScript；
• 末尾的//用于注释掉后续可能拼接的字符串，保证注入代码语法完整、可正常执行；
• 由于news.html页面与目标 JS 同源，document.domain可正常读取，配合仓库 XSS Injection/1 - XSS Filter Bypass.md 中整理的过滤绕过手法（如针对点号、括号、document黑名单的各种 bypass），攻击者可以进一步扩展该 XSS 的实际危害，例如抓取 Cookie、localStorage 中的 access_token 等敏感数据。

从方法论角度，挖掘 CSPT to XSS 的要点是：先在应用中找到一个“路径可控 + 响应体可注入”的组合，再借助../归一化把两者桥接起来。

CSPT to CSRF（CSPT2CSRF）

CSPT 的第二种、也是近年被重点研究的利用方式，是把它转化为 CSRF 攻击。原理是：CSPT 能“重定向”合法的 HTTP 请求，而前端在发起这些请求时会自动附加 API 调用所需的 token（如认证 token 或 CSRF token）。攻击者通过控制请求路径，让携带了合法 token 的请求被发送到自己想要的目标端点，从而绕过现有的 CSRF 防护。

原文档给出了 CSPT2CSRF 与传统 CSRF 的能力对比表（✓ 表示具备该能力，✗ 表示不具备）：

这张表清楚地说明了 CSPT2CSRF 的价值定位：它牺牲了“控制请求体”的能力，换来了对 anti-CSRF token、SameSite=Lax 以及各种 HTTP 方法的全面适配能力。原因在于请求完全由目标应用自己的前端代码发起，浏览器会补全所有认证上下文，攻击者只需要“指路”，不需要“伪造”。

仓库 Cross-Site Request Forgery/README.md 中列出的经典 CSRF 手法（如<img>触发的 GET、自动 submit 的 POST 表单、JSON 简单请求等）在存在 CSPT 的应用中往往失效——因为 token 校验和 SameSite 机制挡住了跨站伪造；而 CSPT2CSRF 正是针对这些防护的“站在应用内部发请求”的破解思路。

真实世界案例

原文档整理了以下已被公开披露的真实场景：

1. Rocket.Chat 中的 1-click CSPT2CSRF：仅需一次点击即可完成攻击。
2. CVE-2023-45316 —— Mattermost 的 POST sink CSPT2CSRF：利用路径/<team>/channels/channelname?telem_action=under_control&forceRHSOpen&telem_run_id=../../../../../../api/v4/caches/invalidate，通过telem_run_id参数注入../，把前端发起的请求重定向到api/v4/caches/invalidate端点。
3. CVE-2023-6458 —— Mattermost 的 GET sink CSPT2CSRF：同样利用 Mattermost 的客户端路径处理缺陷，但 sink 是 GET 型端点。
4. Client Side Path Manipulation（erasec.be 披露）：payload 形如https://example.com/signup/invite?email=foo%40bar.com&inviteCode=123456789/../../../cards/123e4567-e89b-42d3-a456-556642440000/cancel?a=，通过在inviteCode后拼接/../../../把请求引向cards/<card-id>/cancel端点。
5. CVE-2023-5123 —— Grafana JSON API 插件中的 CSPT2CSRF：在 Grafana 生态插件中利用同类缺陷完成 CSRF 攻击。

这些案例表明，CSPT2CSRF 的实战价值已在 Rocket.Chat、Mattermost、Grafana 等主流开源产品中被反复验证，属于真实存在、可被独立复现的漏洞类型，而非纸面推演。

工具与自动化发现

原文档推荐的核心工具如下：

• CSPTBurpExtension（doyensec 出品）：开源的 Burp Suite 扩展，用于发现并利用客户端路径遍历漏洞。它的典型工作流是：先定位前端代码中所有fetch/XHR 调用及其拼接参数，再自动检测哪些拼接点可以被../注入，最后辅助把 CSPT 升级为 XSS 或 CSRF 利用链。

在实际渗透测试中，除了插件自动扫描，还可以手工关注以下模式：

• 前端代码中出现fetch('/xxx/' + param)、/api/v1/${id}之类的字符串拼接；
• 参数值会被 URL 编码后再拼接（编码后..变成%2e%2e%2f，服务端或浏览器归一化后依然生效）；
• 应用存在多个“路径可控 + 响应可注入”端点可以桥接成 XSS 链。

结合仓库纵深：CSPT 与路径遍历编码绕过的协同

CSPT 的核心是../注入，因此所有针对路径遍历的编码绕过技巧（仓库 Directory Traversal/README.md 中有系统整理）同样适用于 CSPT——尤其是当应用或前置 WAF 对../做了简单过滤时。

上述编码在 CSPT 场景中的意义在于：浏览器在解析 URL 时会先解码再归一化，因此只要前端拼接逻辑不限制编码字符，%2e%2e%2f、%c0%ae%c0%ae%c0%af等形态最终仍会被还原成../并完成路径跳转。这也是原文档参考文献中“Bypassing WAFs to Exploit CSPT Using Encoding Levels”研究（Matan Berson，2024-05）所强调的方向：通过多层编码分级（encoding levels）绕过 WAF，再触发 CSPT。

从源码结构看，这类绕过的前提是：1）输入在到达fetch拼接点前没有被彻底规范化；2）浏览器/服务端至少保留一种解码+归一化路径。因此测试时建议把上述编码形态逐一加入 fuzz 字典。

检测与防御建议

结合 CSPT 的成因，防御与检测可从以下角度入手：

检测（红队视角）：

• 审计前端源码中所有fetch/XMLHttpRequest的动态 URL 拼接，重点标记参数直达路径片段的调用；
• 用../、%2e%2e%2f、..././等字典 fuzz 可控参数，观察请求是否被重定向到非预期端点；
• 使用 CSPTBurpExtension 自动化完成“拼接点发现 → 注入验证 → 利用链构建”的闭环。

防御（蓝队/开发视角）：

• 输入白名单校验：路径片段参数应使用严格的正则（如仅允许[a-zA-Z0-9_-]），从源头杜绝..；
• 编码后再校验：对输入先做一次 URL 解码、再做合法性校验，防止双重编码绕过；
• 前端禁止拼接：优先使用带参数的对象式请求（如new URL()并逐段设置 pathname），避免直接字符串拼路径；
• 响应侧防注入：对于可能被 CSPT 指向的 JS 端点，避免把任何查询参数回显到响应体中（消除 text injection，从而切断 CSPT to XSS 链）。

Labs：练习环境

• CSPTPlayground（doyensec 出品）：开源的 CSPT 练习场地（playground），专门用于发现和利用客户端路径遍历，适合验证本文中的所有 payload 与利用链。
• Root Me —— CSPT - The Ruler：在线 Web-Client 挑战题，可用于训练手工挖掘 CSPT 与构造注入链的能力。

建议练习顺序：先在 CSPTPlayground 中复现“CSPT to XSS”的基础链（newsitemid=../xxx.js?cb=payload//这类模式），再尝试把同一思路迁移到 CSPT2CSRF 的 sink 控制上，最后用编码绕过技巧过一遍 WAF 场景。

参考资料与延伸阅读

原文档附带的参考文献覆盖了 CSPT 从 2007 年到 2025 年的关键研究脉络，按其主题可归纳为：

• 概念奠基：Dafydd Stuttard（PortSwigger）于 2007 年提出的 "On-site request forgery" 概念文章——CSPT 的早期称谓即源于此。
• CSPT2CSRF 系统化研究：Maxence Schmitt（Doyensec）于 2024 年发布的系列成果——包括 2024-07-02 的 "Exploiting Client-Side Path Traversal to Perform Cross-Site Request Forgery - Introducing CSPT2CSRF" 博客、同名白皮书（"CSRF is dead, long live CSRF"），以及 OWASP Global AppSec 2024 大会演讲材料。
• 真实漏洞分析：Davwwwx 于 2023-08 披露的 Jupyter 实例 auth token 泄露链（串联 CVE-2023-39968、CVE-2024-22421 与一个 Chromium 浏览器缺陷）。
• WAF 绕过：Matan Berson 于 2024-05 发表的 "Bypassing WAFs to Exploit CSPT Using Encoding Levels"，与仓库 Directory Traversal/README.md 中的编码表可互相印证。
• 自动化发现：Vitor Falcao 于 2024-10 发表的 "Automating Client-Side Path Traversals Discovery"。
• 工具链扩展：Dennis Goodlett 于 2024-12 发表的 "CSPT the Eval Villain Way!"（结合 Eval Villain 进行 CSPT 分析）。
• 文件上传方向：Maxence Schmitt 于 2025-01 发表的 "Bypassing File Upload Restrictions To Exploit Client-Side Path Traversal"，展示了通过文件上传限制绕过触发 CSPT 的新思路。

以上研究共同勾勒出 CSPT 的完整攻击面：从概念提出（2007）到系统化武器化（CSPT2CSRF，2024），再到编码绕过、自动化发现与文件上传等新维度（2024-2025）。对安全研究者而言，CSPT 是一个“成本低、链式价值高”的漏洞类型——它本身可能只是路径拼接缺陷，但借助 XSS 与 CSRF 两条利用链，可以撬动 token 体系、SameSite 防护等现代 Web 安全机制。

• 网络安全
• 应用安全
• 渗透测试