PortSwigger's "User ID controlled by request parameter with data leakage in redirect" Walkthrough
This is a write-up of of PortSwigger Academy’s “user ID controlled by request parameter with data leakage in redirect” lab.
You’ll need a Portswigger Academy account before you get started. Log in and then view the lab at https://portswigger.net/web-security/access-control/lab-user-id-controlled-by-request-parameter-with-data-leakage-in-redirect. This is accessible from the “all labs” view or the access control blog post.
You’ll also need Burp Suite installed and set up with a proxy. We’ve got a guide for that here.
Challenge Information
Click the “Access the Lab” button and you will be taken to a temporary website that is created for your account. This will be in format https://<random string here>.web-security-academy.net/.
We need to get Carlos’ API key through another access control issue where there’s information leaked in a redirect. We’ll need Burp Suite or another mechanism of intercepting and inspecting redirects for this lab (curl would also work).
The website looks like this:
We can click “My Account” to login with username wiener:peter as provided in the challenge description.
The account page shows our own API key:
If you click the “My account” link it will append /my-account?id=wiener to the end of the URL. If we change this to /my-account?id=carlos, it sends us back to the login screen.
Lab Solution
We know there’s something going on with the direct, and we know that we are being redirected (since we’re sent back to the login page), so let’s try inspecting it in Burp Suite.
If you did not have Burp Suite open with the proxy running earlier, then make the /my-account?id=carlos request again.
Then go to Proxy > HTTP History and find the request:
The first request (to /my-account?id=carlos) returns a 302, and then the second request is for /login, which matches the behavior we saw in the browser.
Click the first request, then the bottom half of the window should update to show the request and response information. As already discussed, the response is a 302 redirect to /login:
If we scroll down, however, we see that the page with Carlos’ information was loaded before the user was redirected, so that anyone who’s able to intercept the redirect can steal Carlos’ API key:
Copy the API key (FLH5hTDg629RE4GrpbEjfRdS05pj58dz), go to your browser and click “Submit solution” in the Academy header, and then paste the value in:
And with that, we’ve solved another lab:
