The lab

here is how portswigger describes it

This lab implements access controls based partly on the HTTP method of requests. 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 last lab tied access control to the url and we fooled it by changing which url the back end saw. this one ties the control to something even flimsier, the http method of the request, and the fix is just as blunt, we change the method.

why pinning access control to the method breaks?#

a sound access control check asks one question, is this identity allowed to do this action, and it asks it no matter how the request arrives. the flaw in this lab is that the check is wired to a specific http method. the rule effectively says any POST to this admin function must come from an administrator, and whoever wrote it assumed that admin actions would only ever be POST requests.

that assumption is the hole. if the protection is only attached to POST, then a request that arrives by some other method slips past the check entirely, because there is no rule watching that door. the action itself still works, the server still promotes the user, it is only the guard that was method specific. so our whole job is to keep the request doing the same thing while wearing a different method.

Step 1 - Capture a working promote request as the admin#

we are given admin credentials to study the panel, so we log in as administrator:admin first. the admin panel lets one user promote or demote another.

we trigger a promotion and catch the request in burp, then send it to repeater so we have a known good template to tamper with. the request is a POST that names a user to upgrade.

Step 2 - Confirm a normal user is refused#

now we need our low privileged account's identity on that request. in a separate incognito window we log in as wiener:peter and grab that session cookie.

back in repeater we swap the admin cookie for wiener's and resend the same POST. the app refuses it.

the response says unauthorized, which confirms the access control is doing its job for a POST from a non admin. so a straight replay is out, and we have to get at the function some other way.

Step 3 - Probe how the check reacts to a different method#

before switching to a useful method we poke the server to see whether the method is really what the check keys on. we change POST to a nonsense method like POSTX and send it.

the response changes from unauthorized to missing parameter. that single change tells us everything. the access control no longer fires, because POSTX is not the method it was guarding, and the app has fallen through to trying to actually handle the request, failing only because our parameters were in the wrong place for this new method. the guard is tied to the method, exactly as suspected.

Step 4 - Switch to GET and promote yourself#

now we use a real method the server understands but the check was not watching. we convert the request to GET, which moves the parameters into the query string, and we set the target to our own account so that the promotion lands on us:

GET /admin-roles?username=wiener&action=upgrade HTTP/1.1

with wiener's cookie still attached, the request goes through. the access control was only ever watching POST, so a GET sails past the guard, and the back end carries out the upgrade on wiener.

our account is now an administrator.

with this, the lab is solved!