The lab

here is how portswigger describes it

This lab has an admin panel with a flawed multi-step process for changing a user's role. You can familiarize yourself with the admin panel by logging in using the credentials administrator:admin.

To solve the lab, log in using the credentials wiener:peter and exploit the flawed access controls to promote yourself to become an administrator.

the method based lab had one guarded action and we slipped past the guard by changing the method. this time the action is split across several steps, and the weakness is that the developers guarded the front steps and forgot about the one at the end.

why a multi step action often leaks on the last step?#

some sensitive actions are broken into stages. you pick a user, you are shown a confirmation page, then you confirm, and only then does the change happen. the thinking is that this is safer, but it quietly multiplies the number of places that each need protecting.

the mistake here is assuming that if the first step is locked down, the whole flow is locked down. developers check that you are an admin when you open the role change form, see that guard in place, and feel safe. but the final confirmation step, the request that actually writes the new role, often has no check of its own, because they assumed nobody could reach it without passing through the guarded steps first. that assumption is false. nothing stops us from replaying that final request directly, and if it carries no access control of its own, it does the job for anyone who sends it.

Step 1 - Walk the flow as the Admin to find the real request#

we log in as administrator:admin to learn the process. the panel lets an admin promote or demote users.

we pick carlos and start the upgrade, and instead of acting immediately the app shows a confirmation page asking us to approve the change.

clicking yes is the step that actually matters, because that is the request that commits the new role. we capture it in burp and look at it closely.

it is a POST carrying the username and the action to perform. this is the one request in the whole flow that does the real work, so this is the one we want to replay as a normal user.

Step 2 - Replay the final step as a non admin#

now we test whether that confirmation request checks our privileges at all. in an incognito window we log in as wiener:peter and take that session cookie.

in repeater we drop wiener's cookie into the captured confirmation request and change the username to our own account so the promotion lands on us, then send it.

it goes straight through. the earlier steps in the flow were guarded, but this final commit step never checks who is calling it, so it happily promotes wiener on the say so of a non admin session. we skipped the guarded front door entirely and walked in through the unlocked back one.

with this, the lab is solved!