Broken Access Control is a critical security vulnerability that occurs when a system fails to properly enforce restrictions on what authenticated users are allowed to do. It allows attackers to access unauthorized functionality and data, potentially leading to severe consequences such as data breaches, privilege escalation, and unauthorized actions.
Dangers of Inadequate Access Control:
Data Breaches: Inadequate access controls allowing unauthorized access to sensitive data can lead to data breaches, which reveal private information to uninvited parties.
Privilege Escalation: By taking advantage of weak access controls, attackers can increase their level of privilege within the system and obtain unapproved access to sensitive or administrative resources.
Data Manipulation: Attackers may be able to alter or manipulate data if access restrictions are not correctly implemented, which could compromise data integrity and harm an organization’s finances or reputation.
Unauthorized Actions: By taking advantage of weak access controls, attackers can carry out unauthorized actions including erasing, altering, or stealing data, interfering with system operations, or harming the system and its users.
Lab 1: Unprotected admin functionality
This lab has an unprotected admin panel. It’s located at an unpredictable location, but the location is disclosed somewhere in the application.
Solve the lab by accessing the admin panel, and using it to delete the user carlos.
1. This time there is no information in the robots.txt file. Try viewing the page source.
The admin interface’s URL has been leaked.
Make it with effortless ease
Lab 2: User role controlled by request parameter
This lab has an admin panel at /admin, which identifies administrators using a forgeable cookie.
Solve the lab by accessing the admin panel and using it to delete the user carlos .
1. Attempt to access admin panel upon logging in using wiener/peter:
Admin interface only available if logged as an administrator.
Be mindful that the “admin” field in the cookie has a value of “false.” Change it to “true” before repeating again.
Now Intercept the delete request in Burp suite Proxy and Change admin parameter in cookie to true
Hence The Lab Is Solved …
Lab 3: User role can be modified in user profile
This lab has an admin panel at /admin. It’s only accessible to logged-in users with a roleid of 2.
Solve the lab by accessing the admin panel and using it to delete the user carlos
1. First start with login with provided credentials wiener/peter.
Use the provided feature to update the email address associated with your account.
– Intercept request in Burpsuite Proxy
– Uh’ll see in the response there is one Roleid= parameter
– Send the email submission request to Burp Repeater, add “roleid”:2 into the JSON in the request body, and resend it.
Note: The response shows your roleid has changed to 2
– Copy Show Response n browser from Burpsuite
>Now Uh’ll get access to admin panel.
– Now Delete the user carlos and complete the lab.
Lab 4: User role controlled by request parameter
This lab has an admin panel at /admin, which identifies administrators using a forgeable cookie.
Solve the lab by accessing the admin panel and using it to delete the user carlos.
1. Start with login using the provided credentials wiener/peter.
– Browse to /admin and observe that you can’t access the admin panel
2. In Burp Proxy, turn interception on and enable response interception.
– Now Use the email change feature in application and intercept the request, observe in the cookie there is one admin=false parameter.
– Make it true and access the admin panel.
– Now click delete the user carlos and re-intercept the request in Burpsuite proxy. And make admin admin=true.
– Now the user is deleted and lab is solved successfully.
Lab 5: User ID controlled by request parameter, with unpredictable user IDs
This lab has a horizontal privilege escalation vulnerability on the user account page, but identifies users with GUIDs.
To solve the lab, find the GUID for carlos, then submit his API key as the solution.
– First Login with provided credentials wiener / peter.
– At My-Account page Api-key: is visible.
– Observe in the URL there is one? Id= parameter
– Change the? id= parameter to carlos user’s id to get the Api-key of their user.
– To get the? id= of carlos, Goto blogs section and find a blog written by carlos
– Click on user carlos
– In the URL Uh’ll get the userid= for carlos.
– Copy the carlos userid=
– Now Navigate to My Account Page And use the carlos userid= in the place of wiener userid=
– Now Uh’ll get access to the carlos user api key , Now submit that and solve the lab.
Lab 6: User ID controlled by request parameter with data leakage in redirect
This lab contains an access control vulnerability where sensitive information is leaked in the body of a redirect response
To solve the lab, obtain the API key for the user carlos and submit it as the solution.
– First Start with login using the provided credentials: – Wiener / peter.
– Now Goto My Account Page Send the request to Burp Repeater.
– Send the request to repeater.
– change the username from wiener to carlos.
– Uh’ll get the api key in response , submit it and solve the lab successfully…
Lab 7: User ID controlled by request parameter with password disclosure
This lab has user account page that contains the current user’s existing password, prefilled in a masked input.
To solve the lab, retrieve the administrator’s password, then use it to delete the user carlos.
– First start with login with credentials provided: wiener / peter
– Now Navigate to My Account page
– In the Url, observe there is one? id= parameter
– Change it wiener to administrator
– Now the Password field for administrator is visible
– For convert the Password field from password to text format, navigate to Inspect element on browser OR type CTRL+SHIFT+I to open inspect element
