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 classic path traversal but on the client-side. In particular, it's about tricking how an API works to make requests to the incorrect API. This can be used to get XSS with the wrong content type and several other issues. This paired with open redirects can be useful as well.

On this private in-person competition, the author noticed an API vulnerable to CSPT. This API was used for signing an S3 bucket path on the backend, where the filename was the controlled parameter that was part of the URL. By URL encoding the path, we get /categories/..%2Fredirect%3Furl%3Dmalicious.com that will result in /categories/../redirect. Neat!

By itself, this isn't very helpful, though. A friend of the authors noticed that using ?redirect=true on the API would result in a 301 redirect. This returns the file URL instead of the raw contents of the file. This means that we may be able to get XSS from it!

Initially, they ran into some CORS issues. Since CloudFront was used for caching, it was caching the initial download of the file without the CORS header. When trying to access the file from the page, it would then fail with a CORS violation. By ONLY using the redirect route instead of the regular file download, this issue can be avoided. Sometimes, debugging web things is complicated and annoying.

This XSS is a self-XSS because the store is bound to another account or only during the buying process. The application was vulnerable to a login/logout CSRF as well, giving them another primitive to work with.

The final piece of the puzzle surrounds cookies. Cookies are scoped to a particular path, and there is a limit to the number of cookies that are allowed to be there. Both of these are important for exploitation.

There's the full exploit path:

1. Add the malicious cart item with the self-XSS to a dummy account.
2. Convince a user to click on your web page. Using this site, a logout/login CSRF will happen to log them into the attackers dummy account.
3. Self-XSS is triggered on the dummy account. This will cookie bomb (hit cookie limit) the current session, then add our own cookie at the proper path for the CSPT.
4. The server will force logout the user because of the cookie bomb.
5. Original XSS opens the login page to prompt the user to login again. This is the trick - there are two logged in users now! The actual user and the dummy user at the particular path.
6. Logged in user is redirected to the CSPT vulnerable path for the second XSS payload.
7. The second XSS payload will call any of the state changing APIs they want with the main users creds.

The usage of scoped cookies to have two session cookies be valid is super clever! It's crazy how much effort was required to exploit this. Client-side security is baffling to me.