HackerOne · Report #301862
Path traversal leading to limited CSRF on GET requests on two endpoints
Summary
The issue could not be exploited directly, and therefore is a theoretical issue. It was reported after having a convo with @jobert. I'm not sure, but the request probably added a CSRF token (or equivalent) header, which made it interesting for further exploitation. For example, if there's a state-changing endpoint (or open redirect) over GET somewhere, which requires (or has) an additional authorization/CSRF header, this issue could become interesting.
I hope to make it clear with this summary since the impact I described in the report is describing a totally different issue.
How it was found
Hi team!
I've found more endpoints which are vulnerable to the limited CSRF stated in report https://hackerone.com/reports/99708. The endpoints cause a CSRF over GET requests, however, I've been unable to exploit it.
The following endpoints are vulnerable to this:
Proof of Concept
- Visit https://hackerone.com/users/confirmation?confirmation_token=z2-aaa&invitation_token=/../../test or https://hackerone.com/users/password/new?invitation_token=/../../test (the two endpoints which are still vulnerable)
- Inspect the network traffic via developer tools or an intercepting proxy, and notice a request being made to https://hackerone.com/test.json.
We can get HackerOne to authorize Slack within a team (as attempted to do so in report 99708), however due to the state parameter it will be hard to exploit that one unless an attacker is able to get the state parameter from the victim.
Impact
As mentioned above, it will have a big impact on HackerOne if an attacker is able to get the state parameter of the victim to, as it would lead to reports being leaked.