Exploiting Client-Side Path Traversal to Perform Cross-Site Request Forgery - Introducing CSPT2CSRF
02 Jul 2024 - Posted by Maxence Schmitt
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?
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.
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.
Finally, we are releasing a Burp extension to help discover Client-Side Path-Traversal sources and sinks.
Thanks to the Mattermost and Rocket.Chat teams for their collaboration and authorization to share this.
Client-Side Path Traversal (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.
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:
- a tweet from Sam Curry back in 2021
- 1-click CSRF in GitLab by Johan Carlsson
- CSS Injection by Medi, nominated in the Portswigger Top 10 Web hacking techniques of 2022
- a CSRF by Antoine Roly from Erasec
- Some other references were found about Client-Side CSRF from OWASP and in this research paper by Soheil Khodayari and Giancarlo Pellegrino.
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.
Client-Side Path Traversal to Perform Cross-Site Request Forgery (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).
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):
- URL fragment
- URL Query
- 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.
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).
Each CSPT2CSRF needs to be described (source and sink) to identify the complexity and severity of the vulnerability.
As an attacker, we want to find all impactful sinks that share the same restrictions. This can be done with:
- API documentation
- Source code review
- Semgrep rules
- Burp Suite Bambda filter
CSPT2CSRF with a GET Sink
Some scenarios of exploiting CSPT with a GET sink exist:
- 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
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.
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.
In fact it is often possible to chain a CSPT2CSRF having a GET sink with another state-changing CSPT2CSRF.
1st primitive: GET CSPT2CSRF:
- Source:
idparam in the query - Sink: GET request on the API
2nd primitive: POST CSPT2CSRF:
- Source:
idfrom the JSON data - Sink: POST request on the API
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.
In the whitepaper, we explain this scenario with an example in 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.
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.
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.
More information
If you would like to learn more about our other research, check out our blog, follow us on X (@doyensec) or feel free to contact us at info@doyensec.com for more information on how we can help your organization “Build with Security”.