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

“Incrementally Better Cookies”（逐步改进的 Cookie）的计划，旨在解决 CSRF 和其他客户端安全问题。

随后，Chrome 等浏览器实施了这些改动，引入了 SameSite 属性，有效缓解了 CSRF 攻击。但这是否意味着 CSRF 攻击已不再构成威胁？

在对主流 Web 应用进行安全审计时，我们发现客户端路径遍历（CSPT）可以被用来恢复 CSRF 攻击，给渗透测试人员带来了新的挑战。

这篇博客是对我研究的简要介绍，详细的研究成果、方法论以及深入分析可以在发布的白皮书中找到。

https://www.doyensec.com/resources/Doyensec_CSPT2CSRF_Whitepaper.pdf

我们的研究从客户端路径遍历的基础入手，展示 CSRF 攻击中常见的源点（sources）和 汇点（sinks）。

为了验证这一发现的影响力与创新性，我们分析并展示了多个主流 Web 消息应用中的漏洞，包括 Mattermost 和 Rocket.Chat 等。

此外，为了帮助安全研究人员更高效地发现 CSPT 源点和汇点，我们发布了一款 Burp Suite 插件。

插件： 

https://github.com/doyensec/CSPTBurpExtension

客户端路径遍历 

每位安全研究人员都应该了解路径遍历漏洞。

路径遍历使攻击者可以通过类似于../../../../的有效载荷读取超出预期目录范围的数据。

然而，与服务器端路径遍历攻击（通常用于读取服务器上的文件）不同，客户端路径遍历攻击的目标是利用这种漏洞发送请求到不受预期控制的 API 端点。

尽管路径遍历漏洞在服务器端应用中非常常见，但客户端路径遍历的相关案例却鲜有曝光。

我们找到的首个案例是 Philippe Harewood 在 Facebook 漏洞赏金计划中报告的一个漏洞。

从那时起，与客户端路径遍历相关的参考资料寥寥可数，包括：

长期以来，客户端路径遍历漏洞经常性被忽视。尽管许多人将其视为影响较低的漏洞。

但实际上，它可以用于强制终端用户在 Web 应用程序上执行未授权的操作，这种潜在危害使其成为值得深入研究和防御的重要攻击面。

实现跨站请求伪造

本次研究起源于我们在 Web 安全评估中多次利用客户端路径遍历漏洞的经历。

然而，我们发现缺乏足够的文档和知识来探讨如何利用客户端路径遍历实施 CSRF 攻击（即 CSPT2CSRF）的界限和潜在影响。

来源（Source）

在研究过程中，我们注意到一个普遍的认知偏见：

研究人员通常认为用户输入必须来自前端。然而，与 XSS 类似，任何用户输入都可能导致 CSPT（例如 DOM、反射型、存储型路径遍历），常见的来源包括：

• URL 片段
• URL 查询参数
• 路径参数
• 数据库中注入的数据

评估来源时，还需要考虑漏洞是否需要特定的用户操作触发，或者是否在页面加载时自动触发。这种复杂性将直接影响漏洞的最终严重性。

接收端（Sink）

CSPT 会重定向合法的 API 请求。因此，攻击者可能无法完全控制 HTTP 方法、请求头和请求体。这些限制与漏洞来源密切相关。

同一个前端代码中可能存在不同的来源，每个来源触发的行为（如 GET/POST/PATCH/PUT/DELETE）可能不同。

每个 CSPT2CSRF 攻击都需要明确描述其来源（Source）和接收端（Sink），以便准确评估漏洞的复杂性和严重性。

攻击者的目标

作为攻击者，我们需要找到共享相同限制条件的所有高影响接收端。实现这一目标的方法包括：

• 查看 API 文档
• 进行 源代码审查
• 使用 Semgrep 规则
• 使用 Burp Suite Bambda 过滤器

CSPT2CSRF 的 “Bambda”

“Bambda” 工具是我们在研究中开发的辅助插件，旨在帮助安全研究人员快速发现客户端路径遍历漏洞的来源和接收端。

借助此工具，可以更高效地评估漏洞的潜在影响和利用价值。

ounter(lineounter(lineounter(lineounter(lineounter(lineounter(linebooleanmatches (ProxyHttpRequestResponse requesstResponse)boolean isCorrectHost = requestResponse.request().httpServiice().host().equalsIgnoreCase("api.target.com");boolean isPostRequest = requestResponse.request().method().equalsIgnoreCase("POST");boolean isJSON = requestResponse.request().hasParameters(HttpParameterType.JSON);boolean hasMandatoryParam = requestResponse.request().hasParameter("organizationId", HttpParameterTypeJSON);return isCorrectHost && isPostRequest && isJSON &&hasMandatoryParam;

利用 GET Sink 的 CSPT2CSRF

在一些场景中，可以通过利用 Client-Side Path Traversal (CSPT) 和 GET Sink 来实现攻击：

1. 通过开放重定向泄露敏感数据：

   利用开放重定向将与源相关的敏感数据泄露到攻击者控制的 URL。

2. 通过开放重定向加载恶意数据：

   通过开放重定向加载攻击者提供的恶意数据，从而触发 XSS 攻击。

挑战：现代环境下的限制

由于开放重定向漏洞被大量安全研究人员关注，前端框架的安全性提升（如现代框架对 XSS 的防护），寻找这些漏洞的难度大幅增加。

尽管如此，研究表明，即使某些状态更改操作没有直接使用 GET Sink，也可以通过 CSPT2CSRF 成功利用，而无需依赖开放重定向或触发 XSS。

CSPT2CSRF 的链式攻击

在实际应用中，通常可以将一个具有 GET Sink 的 CSPT2CSRF 与另一个状态更改型的 CSPT2CSRF 进行链式组合。

通过这种方式，即使单独的漏洞看似影响有限，结合起来也可以执行更复杂的攻击，进而影响系统的核心功能或破坏业务逻辑。

这种链式利用展示了 CSPT2CSRF 的多样性和灵活性，尤其是在现代应用中，当单点攻击不足以实现目标时，链式攻击成为一种强大的手段。

1. 第一原语：GET CSPT2CSRF
• 来源：查询参数中的 id 参数
• 接收点： 针对 API 的 GET 请求
2. 第二原语：POST CSPT2CSRF
• 来源： JSON 数据中的 id 字段。
• 接收点： 针对 API 的 POST 请求。

为了将这些原语进行链式利用，必须找到一个 GET sink gadget，并且攻击者需要能够控制返回的 JSON 中的 id。

有时，后端可能会直接授权返回的 JSON 数据，但我们发现最常见的 gadget 是滥用文件上传/下载功能。

实际上，许多应用在其 API 中暴露了文件上传功能，攻击者可以上传包含伪造 id 的 JSON 文件，并以此为目标内容触发 CSPT2CSRF，从而实现状态更改等操作。

在白皮书中，我们通过一个 Mattermost 的实例说明了这一场景。

技术点评部分会分析这部分案例

分享于社区

这项研究上周由 Maxence Schmitt（@maxenceschmitt）在 2024 年 OWASP Global AppSec Lisbon 大会上进行了展示。

演示文稿可以通过此处查看。

https://www.doyensec.com/resources/Doyensec_CSPT2CSRF_OWASP_Appsec_Lisbon.pdf

这篇博客只是我们广泛研究的一个简要概述。要全面了解并获得详细的技术洞察，请参阅我们的白皮书。

此外，我们还发布了一款 BURP 插件，用于发现客户端路径遍历漏洞。

总结

我们认为 CSPT2CSRF 在许多安全研究人员中被忽视，而大多数前端开发人员对此类漏洞更是一无所知。

我们希望这项工作能够突出这一类漏洞，并帮助安全研究人员和防御者更好地保护现代应用程序的安全。

技术点评

这是一个通过漏洞利用链进行攻击的过程。

首先，攻击者需要找到一个客户端路径遍历（Client-Side Path Traversal，CSPT）漏洞。

通常，前端拼接请求路径时并不会进行过滤，许多人在开发时都忽视了这一点，因此这个 Source 点便暴露了漏洞。

一旦找到这个 Source 点，攻击者可以控制路径并发起请求，结合前端的设计，如果应用使用的是统一的 API 接口，那么请求很可能会经过拦截器。

在此过程中，拦截器通常会自动加入鉴权信息和防止 CSRF 攻击的 token。这时，攻击者便有可能绕过 CSRF 防护，针对某些 Sink 端点发起攻击。

特别是像删除操作这样的端点，往往不需要传递复杂的参数。在这种情况下，后端可能没有严格验证请求的结构，或某些操作可能无需额外的参数。这使得 CSRF 攻击在这种场景下的危害尤为严重。

尽管如此，这种攻击方式还是受到一定限制的，具体效果取决于前后端的实现细节。

白皮书提供了三个经典真实案例，以其中 Mattermost 作为说明：

攻击步骤如下：

1.受害者在浏览器浏览恶意链接

http://localhost:8065/doyensec/channels/channelname?telem_action=under_control&forceRHSOpen&telem_run_id=../../../../../../api/v4/caches/invalidate

2.前端会提取 telem_run_id 拼接 API 请求路径，造成自动对 api/v4/caches/invalidate 端点发起如下请求

3.危害升级，寻找更严重的端点：/api/v4/plugins/install_from_url?plugin_download_url=xxxx=&force=true 造成 RCE

需要白皮书研究更复杂的案例可以在公众号回复暗号: "20250111" 获取

thanks for https://blog.doyensec.com/2024/07/02/cspt2csrf.html

文末点评

这个技术自己之前也有想过，不过当时只考虑到将 GET 类型的站内重定向漏洞扩大危害由 GET 转为 POST 进行CSRF攻击，但确实没想到客户端路径遍历的思路，所以这个技术确实很牛B，直接攻破CSRF防御，一下子打开了非常多的攻击面！

最后，关注 一个不正经的黑客 公众号，带你学习更多前沿精彩技术！