To provide users with a safer browsing experience, the IETF proposal named “Incrementally Better Cookies” set in motion a few important changes to address Cross-Site Request Forgery (CSRF) and other client-side issues. Soon after, Chrome and other major browsers implemented the recommended changes and introduced the SameSite attribute. SameSite helps mitigate CSRF, but does that mean CSRF is dead?
为了给用户提供更安全的浏览体验，IETF 提案名为“Incrementally Better Cookies”，启动了一些重要的更改，以解决跨站点请求伪造 （CSRF） 和其他客户端问题。不久之后，Chrome 和其他主要浏览器实施了建议的更改并引入了 SameSite 属性。SameSite 有助于缓解 CSRF，但这是否意味着 CSRF 已死？

While auditing major web applications, we realized that Client Side Path-Traversal (CSPT) can be actually leveraged to resuscitate CSRF for the joy of all pentesters.
在审计主要 Web 应用程序时，我们意识到客户端路径遍历 （CSPT） 实际上可以用来恢复 CSRF，让所有渗透测试人员都感到高兴。

This blog post is a brief introduction to my research. The detailed findings, methodologies, and in-depth analysis are available in the whitepaper.
这篇博文是对我的研究的简要介绍。白皮书中提供了详细的发现、方法和深入分析。

This research introduces the basics of Client-Side Path Traversal, presenting sources and sinks for Cross-Site Request Forgery. To demonstrate the impact and novelty of our discovery, we showcased vulnerabilities in major web messaging applications, including Mattermost and Rocket.Chat, among others.
本研究介绍了客户端路径遍历的基础知识，介绍了跨站点请求伪造的源和接收器。为了展示我们发现的影响和新颖性，我们展示了主要 Web 消息应用程序中的漏洞，包括 Mattermost 和 Rocket.Chat 等。

Finally, we are releasing a Burp extension to help discover Client-Side Path-Traversal sources and sinks.
最后，我们将发布一个 Burp 扩展，以帮助发现客户端路径遍历源和接收器。

Thanks to the Mattermost and Rocket.Chat teams for their collaboration and authorization to share this.
感谢 Mattermost 和 Rocket.Chat 团队的合作和授权分享。

Client-Side Path Traversal (CSPT)
客户端路径遍历 （CSPT）

Every security researcher should know what a path traversal is. This vulnerability gives an attacker the ability to use a payload like ../../../../ to read data outside the intended directory. Unlike server-side path traversal attacks, which read files from the server, client-side path traversal attacks focus on exploiting this weakness in order to make requests to unintended API endpoints.
每个安全研究人员都应该知道什么是路径遍历。此漏洞使攻击者能够使用有效负载，例如 ../../../../ 读取预期目录之外的数据。与从服务器读取文件的服务器端路径遍历攻击不同，客户端路径遍历攻击侧重于利用此弱点向意外的 API 端点发出请求。

While this class of vulnerabilities is very popular on the server side, only a few occurrences of Client-Side Path Traversal have been widely publicized. The first reference we found was a bug reported by Philippe Harewood in the Facebook bug bounty program. Since then, we have only found a few references about Client-Side Path Traversal:
虽然这类漏洞在服务器端非常流行，但只有少数客户端路径遍历被广泛宣传。我们发现的第一个参考资料是 Philippe Harewood 在 Facebook 漏洞赏金计划中报告的一个漏洞。从那时起，我们只找到了一些关于客户端路径遍历的参考资料：

• a tweet from Sam Curry back in 2021
  山姆·库里 （Sam Curry） 在 2021 年的一条推文
• 1-click CSRF in GitLab by Johan Carlsson
  一键式 CSRF in GitLab 作者：Johan Carlsson
• CSS Injection by Medi, nominated in the Portswigger Top 10 Web hacking techniques of 2022
  Medi 的 CSS 注入，被提名为 2022 年 Portswigger 十大网络黑客技术
• a CSRF by Antoine Roly from Erasec
  来自 Erasec 的 Antoine Roly 的 CSRF
• Some other references were found about Client-Side CSRF from OWASP and in this research paper by Soheil Khodayari and Giancarlo Pellegrino.
  在OWASP的客户端CSRF以及Soheil Khodayari和Giancarlo Pellegrino的这篇研究论文中，发现了一些关于客户端CSRF的参考资料。

Client Side Path-Traversal has been overlooked for years. While considered by many as a low-impact vulnerability, it can be actually used to force an end user to execute unwanted actions on a web application.
客户端路径遍历多年来一直被忽视。虽然许多人认为这是一个低影响的漏洞，但它实际上可用于强制最终用户在 Web 应用程序上执行不需要的操作。

Client-Side Path Traversal to Perform Cross-Site Request Forgery (CSPT2CSRF)
客户端路径遍历以执行跨站点请求伪造 （CSPT2CSRF）

This research evolved from exploiting multiple Client-Side Path Traversal vulnerabilities during our web security engagements. However, we realized there was a lack of documentation and knowledge to understand the limits and potential impacts of using Client-Side Path Traversal to perform CSRF (CSPT2CSRF).
这项研究是从在我们的 Web 安全活动期间利用多个客户端路径遍历漏洞演变而来的。但是，我们意识到缺乏文档和知识来了解使用客户端路径遍历执行 CSRF 的局限性和潜在影响 （CSPT2CSRF）。

Source 源

While working on this research, we figured out that one common bias exists. Researchers may think that user input has to be in the front end. However, like with XSS, any user input can lead to CSPT (think DOM, Reflected, Stored):
在进行这项研究时，我们发现存在一种常见的偏见。研究人员可能认为用户输入必须在前端。但是，与 XSS 一样，任何用户输入都可能导致 CSPT（想想 DOM、Reflected、Stored）：

• URL fragment URL 片段
• URL Query URL 查询
• Path parameters 路径参数
• Data injected in the database
  注入数据库的数据

When evaluating a source, you should also consider if any action is needed to trigger the vulnerability or if it’s triggered when the page is loaded. Indeed, this complexity will impact the final severity of the vulnerability.
在评估源时，还应考虑是否需要执行任何操作来触发漏洞，或者是否在加载页面时触发该漏洞。事实上，这种复杂性将影响漏洞的最终严重性。

Sink 沉

The CSPT will reroute a legitimate API request. Therefore, the attacker may not have control over the HTTP method, headers and body request.
CSPT 将重新路由合法的 API 请求。因此，攻击者可能无法控制 HTTP 方法、标头和正文请求。

All these restrictions are tied to a source. Indeed, the same front end may have different sources that perform different actions (e.g., GET/POST/PATCH/PUT/DELETE).
所有这些限制都与来源相关联。事实上，同一个前端可能有不同的源来执行不同的操作（例如，GET/POST/PATCH/PUT/DELETE）。

Each CSPT2CSRF needs to be described (source and sink) to identify the complexity and severity of the vulnerability.
需要描述每个CSPT2CSRF（源和接收器），以确定漏洞的复杂性和严重性。

As an attacker, we want to find all impactful sinks that share the same restrictions. This can be done with:
作为攻击者，我们希望找到具有相同限制的所有有影响力的接收器。这可以通过以下方式完成：

• API documentation API 文档
• Source code review 源代码审查
• Semgrep rules Semgrep 规则
• Burp Suite Bambda filter
  打嗝套房 Bambda 过滤器

CSPT2CSRF with a GET Sink
使用 GET Sink 进行CSPT2CSRF

Some scenarios of exploiting CSPT with a GET sink exist:
存在一些利用带有 GET 接收器的 CSPT 的方案：

• Using an open redirect to leak sensitive data associated with the source
  使用开放重定向泄漏与源关联的敏感数据
• Using an open redirect to load malicious data in order to trigger an XSS
  使用开放重定向加载恶意数据以触发 XSS

However, open redirects are now hunted by many security researchers, and finding an XSS in a front end using a modern framework may be hard.
然而，开放重定向现在被许多安全研究人员所追捕，并且使用现代框架在前端找到 XSS 可能很困难。

That said, during our research, even when stage-changing actions weren’t implemented directly with a GET sink, we were frequently able to exploit them via CSPT2CSRFs, without having the two previous prerequisites.
也就是说，在我们的研究过程中，即使没有直接使用 GET 接收器实现阶段更改操作，我们也经常能够通过 CSPT2CSRF 来利用它们，而无需满足前两个先决条件。

In fact it is often possible to chain a CSPT2CSRF having a GET sink with another state-changing CSPT2CSRF.
事实上，通常可以将具有 GET 接收器的CSPT2CSRF与另一个状态更改CSPT2CSRF链接起来。

1st primitive: GET CSPT2CSRF:
第一个原语：GET CSPT2CSRF：

• Source: id param in the query
  来源： id 参数 在查询中
• Sink: GET request on the API
  接收器：API 上的 GET 请求

2nd primitive: POST CSPT2CSRF:
第二个原语：POST CSPT2CSRF：

• Source: id from the JSON data
  来源： id 来自 JSON 数据
• Sink: POST request on the API
  接收器：API 上的 POST 请求

To chain these primitives, a GET sink gadget must be found, and the attacker must control the id of the returned JSON. Sometimes, it may be directly authorized by the back end, but the most common gadget we found was to abuse file upload/download features. Indeed, many applications exposed file upload features in the API. An attacker can upload JSON with a manipulated id and target this content to trigger the CSPT2CSRF with a state-changing action.
若要链接这些基元，必须找到 GET 接收器小工具，并且攻击者必须控制返回的 JSON。 id 有时，它可能由后端直接授权，但我们发现最常见的小工具是滥用文件上传/下载功能。事实上，许多应用程序都公开了 API 中的文件上传功能。攻击者可以上传具有操纵 id 的 JSON，并以此内容为目标，以通过状态更改操作触发CSPT2CSRF。

In the whitepaper, we explain this scenario with an example in Mattermost.
在白皮书中，我们用 Mattermost 中的一个例子来解释这个场景。

Sharing with the Community
与社区共享

This research was presented last week by Maxence Schmitt (@maxenceschmitt) at OWASP Global Appsec Lisbon 2024. The slides can be found here.
这项研究由Maxence Schmitt（@maxenceschmitt）上周在OWASP Global Appsec Lisbon 2024上发表。幻灯片可以在这里找到。

This blog post is just a glimpse of our extensive research. For a comprehensive understanding and detailed technical insights, please refer to the whitepaper.
这篇博文只是我们广泛研究的一瞥。如需全面了解和详细的技术见解，请参阅白皮书。

Along with this whitepaper, we are releasing a BURP extension to find Client-Side Path Traversals.
除了本白皮书，我们还发布了一个 BURP 扩展，用于查找客户端路径遍历。

In Conclusion 综上所述

We feel CSPT2CSRF is overlooked by many security researchers and unknown by most front-end developers. We hope this work will highlight this class of vulnerabilities and help both security researchers and defenders to secure modern applications.
我们觉得CSPT2CSRF被许多安全研究人员忽视了，而大多数前端开发人员却不知道。我们希望这项工作能够突出这类漏洞，并帮助安全研究人员和防御者保护现代应用程序。

原文始发于doyensec：Exploiting Client-Side Path Traversal to Perform Cross-Site Request Forgery – Introducing CSPT2CSRF