Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

Client-side path traversal (CSPT) is a vulnerability where routing decisions can be controlled by a user-controlled value in the PATH parameter. For instance, the ID in the URL is set to ../../ID. On the frontend, this is then used on an API request. However, the ../../ID can change the routing of the request.

Cross-site request forgery (CSRF) is a classic vulnerability that has become harder and harder to do over time with A) knowledge of it and B) browser protections like same-site cookies. They wanted to combine these issues to allow for CSRF to still work in some cases.

CSPT will route a legitimate request. This can be used for CSRF-like attacks. Much of the time, there is no control over the HTTP method, headers, or body of the requests.

Sometimes, data is returned and then acted upon. When using a GET sink for CSPT, there is sometimes a response that contains the ID that is then used on future requests, such as state-changing POST requests. This allows for forcing the user to create arbitrary requests that shouldn't usually be possible. There's a key to this though: what data do we want to be returned from the GET request? The attacker must control the ID or routing value of the JSON. This can be achieved by exploiting file upload/download features to contain the content initially. Then, the state-changing action can occur.

They found an instance of this on the Mattermost chat application. An ID for telem_run_id in the URL was used in the routing that was vulnerable to CSPT. The only data being returned in the response that can be used is the action. This provides a minimal CSRF vuln with specific restrictions.

The whitepaper describes how important it is to know the limitations. Once you have this, you can explore more effective ways to exploit the issue. In this case, a single parameter is controlled in the POST request. However, arbitrary data can be put onto the path, including parameters. Knowing these restrictions, they noticed that the plugin installation process only required a single URL parameter. So, this led to RCE!

On Mattermost, they discovered a GET-to-POST-based sink. They uploaded a file to /api/v4/files to then use the returned data from the GET request in the POST request. Same as the previous issue, this led to RCE via URL parameters.

Overall, this is a good bug class to call out. It's somewhat new, which means many applications are likely to be vulnerable to it. It's a first-come-first-server game!