Summary
PortSwigger Web Security Academy Walkthrough: User Role Can Be Modified in User Profile Exploitation Of Broken Access Control Vulnerability. Lab Introduction- In this PortSwigger Web Security Academy lab, the application has an administrator panel available at /admin . However, the panel is restricted to logged-in users whose roleid is set to 2 . The objective is to gain administrator access and use the admin panel to delete the user carlos. The credentials provided by the lab are: Username: wiener Password: peter For this lab, I used Burp Suite to intercept and inspect the application’s HTTP requests and responses. Step 1: Access the Lab I started by clicking the “Access the lab” button to launch the PortSwigger lab environment. Once the application opened, I navigated to My Account and logged in using the credentials provided by the lab: wiener:peter After successfully logging in, I began examining the application’s requests through Burp Suite. Step 2: Inspect the HTTP History I opened Burp Suite → Proxy → HTTP history and reviewed the requests generated while interacting with the application. While going through the requests, I noticed a request related to changing the email address: /my-account/change-email The request itself was interesting, but the response caught my attention because it contained information about the user’s role. In the response, I found the following parameter: “roleid”: 1 The value 1 indicated that my account currently had a normal-user role. Since the lab description stated that the admin panel was accessible to users with a roleid of 2 , this parameter immediately became an interesting target for further testing. Step 3: Send the Request to Repeater I sent the relevant request to Burp Suite Repeater so that I could safely modify the request and observe how the application handled the changes. In Repeater, I modified the request by adding the roleid parameter with the value 2 . Get Vivek Yadav’s stories in your inbox Join Medium for free to get updates from this writer. The modified request included the user’s email information along with the new role value, effectively attempting to change the account from: roleid=1 to: roleid=2 I then sent the modified request. Step 4: Observe the Response After sending the modified request, the server responded with: HTTP/2 302 Found The response indicated that the request had been accepted and the application redirected me. At this point, I suspected that the roleid value had been successfully modified. Step 5: Access the Admin Panel I then attempted to access the administrator panel directly by navigating to: /admin Instead of receiving an access-denied response, I was successfully able to access the Admin Panel. This confirmed that my account had been elevated to the required administrator role. The panel displayed a list of users, including: wiener carlos Step 6: Delete Carlos Inside the Admin Panel, I located the user carlos. I clicked the Delete option associated with the carlos account. After the user was successfully deleted, the PortSwigger Web Security Academy lab reported that the lab had been solved. What Caused the Vulnerability? The key issue in this lab is that the application allowed the user’s roleid to be modified through a user-profile-related request. The application expected: roleid = 1 for a normal user and: roleid = 2 for an administrator. Because the application failed to properly restrict modification of this value, I was able to change my own role from a regular user to an administrator. This resulted in a privilege escalation vulnerability and allowed access to functionality that should have been restricted to administrators. Key Takeaway This lab demonstrates why applications should never allow users to modify security-sensitive attributes such as their own role or privilege level. The server should enforce authorization independently of user-controlled parameters. Even if a request contains a value such as roleid=2 , the application should verify that the user is actually authorized to obtain that role. The overall attack flow was: Login as wiener ↓ Capture requests with Burp Suite ↓ Find /my-account/change-email ↓ Notice the roleid parameter ↓ Modify roleid from 1 → 2 ↓ Send the request ↓ Access /admin ↓ Delete carlos ↓ Lab solved This makes the lab a good example of privilege escalation caused by improper access control over user-profile data. GoodByeeee…..