Access Control on an's security blog

Referer-based access control | Apprentice

Thu, 11 Jun 2026 15:50:16 +0800

We are given the option to try out admin perms for ourselves. When we try to upgrade carlos credentials, we can intercept the request and see what’s behind the scene: Unlike the previous labs, the request to elevate one’s credentials is simply a GET request. If the web app accepts Referer arbitrarily, we can simply change the session cookie to ours and solve the lab.

Multi-step process with no access control on one step | Apprentice

Thu, 11 Jun 2026 15:33:16 +0800

We are given the option to try out admin perms for ourselves. When we try to upgrade carlos credentials, there is a intermediary step that asks us to confirm our decision. Upon interception, we see that this is expressed as a param confirmed:

Hypothetically, the web app may see that confirmed=true is indeed included in the form parameters, and assumes that the person requesting this has valid credentials because they cannot have known that third confirmation step.

Method-based access control can be circumvented | Apprentice

Thu, 11 Jun 2026 13:59:16 +0800

Took too damn long tinkering with Burp while in fact I can just paste the payload into the URL

We are given the choice to first log in the administrator account to see what’s behind the scene. While we are changing carlos privilege, we can intercept the request: Now we know that /admin-roles is the endpoint for changing perms, with username and action as its params. However when we attempt to send the POST request as wiener, we will be hit with Method Not Allowed.

URL-based access control can be circumvented | Apprentice

Thu, 11 Jun 2026 10:49:16 +0800

If we are doing this blind, we can actually append the X-Original-URL header (or equivalent) into the request and add a nonsensical endpoint, e.g. /asdfklsdjflks. If the server gives us a Not Found, that means the backend code is processing X-Original-URL blindly and we can insert our payload, per se.

Thus we can add ?username=carlos into the query string, then change the X-Original-Url path to /admin/delete. The carlos user will be deleted afterwards.

User role can be modified in user profile | Apprentice

Thu, 11 Jun 2026 10:05:16 +0800

At first, I keep digging session cookies and HTML source to see whether they contain any references of roleid or not, and I stumped. I realised that I hadn’t even attempted to change my email to see what happens yet.

So, upon changing our email, we can observe that the response has a JSON object that keeps tab of our username, email, and roleid: Simply add "roleid":2 into the request body and voila we will get access to the admin panel. This is a vuln called Mass Assignment

Unprotected admin functionality with unpredictable URL | Apprentice

Thu, 11 Jun 2026 09:38:16 +0800

Very straightforward, the lab introduces a vuln where sensitive endpoints are exposed in plaintext, in this case some JS scripts: Simply access the hidden endpoint and we can solve the lab.

User role controlled by request parameter | Apprentice

Tue, 02 Jun 2026 15:00:16 +0800

We can simply intercept the request to /admin and change the cookie as follow: After that, we can delete the user carlos and solve the lab.

Unprotected Admin Functionality | Apprentice

Tue, 02 Jun 2026 14:43:16 +0800

Just as the name implies, we are set out to look for an admin panel. Simply access robots.txt that they convieniently left for us: From there we can delete the carlos user from the server.

Besides accessing robots.txt, we can also utilise the Site Map feature of Burp Suite as follow: