Broken access control simply refers to a situation in which an application or system’s intended permissions are violated and attackers can access, alter, delete, or do other actions. Broken access control refers to many vulnerabilities, such as when regular users can access admin-only functionality by modifying URL parameters or seeing or updating another user’s data.
Examples of Broken Access Control
Insecure ID’s: Most of the time, we utilize a unique ID when searching for something in a database. This ID is frequently used in the URL to indicate what data the user wishes to obtain. For example, if I’m logged in to a website, my user ID is 10. The URL for my personal profile page is similar to this: https://example.com/profile?id=10. There’s a chance that this page contains private information that only you should see. But what if I swap out the ID for the ID of another user? The profile page of another person, including all of their private data, will be displayed to me if the website is configured incorrectly. For example, if I visit https://example.com/profile?id=42. How can I find out another user’s ID? Using arbitrary user IDs that are kept secret does make things a little harder, but this is far from sufficient security. This is an excellent illustration of “security by obscurity,” which is generally regarded as bad practice. Implementing appropriate access control in the server is a superior approach, as it prevents it from providing the user with the requested data if they are not authorized to view it.
When a user tries to access resources that are still available but are not referenced by the application. For instance, a web application may include an admin page, but since there is no connection to it on other pages of the website, an ordinary user cannot access it by simply browsing the website. However, if the access control is flawed and someone changes the URL directly, such as by visiting https://example.com/admin, they might be able to access the admin page.
Bug Bounty
This is the most common vulnerability you’ll find in applications these days, The most common example of this is Insecure Direct Object Reference (IDOR), about two months ago, a security researcher earned a bounty $11,500 on a mass account takeover at https://app.taxjar.com/, you can see the full report here. So, it’s just like we say, hard to get but easy to notice!
Practical Labs:
Before starting the practical learning, if you’re new to this series, do check out the introductory blog, to stay on the same page as everyone.
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.
After accessing the lab we see a shop page, to check if something is disclosed we’ll first check the source code by simple doing Ctrl+U,
we found the disclosed source code and the admin path /admin-z28hzh, now we’ll add the path to url and delete the user carlos, mine will be like this:
https://0a1e00f0032f0aa8c0a13e95003d0057.web-security-academy.net/admin-z28hzh
Now, delete the user carlos and submit the solution.
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.
You can log in to your own account using the following credentials: wiener:peter
We’re going to use burp suite this time as some of you are having issues with network tab in chrome tools, to set up Burp Suite + Chrome see this video.
So, to solve this lab we’ll modify the cookie parameter to get us the to admin role, go to my account and login with credentials and intercept the request with burpsuite:
We can see the request in burp suite as:
Observe that Admin=False
change it to Admin=True, and it’ll get you to admin panel, from there delete the user carlos, to solve the
Note: Make sure to set Admin to True everytime you make a request or else it’ll get you back to normal user.
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 carlos.
You can log in to your own account using the following credentials: wiener:peter
Go to my account page, after login in, you’ll see wiener in the user id,
https://0a58007604b09b0dc062440900980034.web-security-academy.net/my-account?id=wiener
change it to administrator and intercept the request and sent it to repeater Ctrl+R to see the password.
Conclusion:
So, we’ve covered the basic theoretical and practical knowledge to understand What command injection vulnerability is and how to exploit it hands-on, we also covered how we can capture the request, modify it, and resend again using Burp Suite. If you’re interested in information disclosure check out my blog, we only covered the basic practical labs and the remaining of them are for you to practice and get more familiar with it and learn your own way through it, you will find video solutions of the labs under the “community solutions” section, and you can also find the writeups for them, but if you’re having any problem with anything feel free to contact me I’ll reply asap. So today’s topic is done here hope you guys liked it and learn something new from it, I will appreciate the support from you guys. Thanks for reading, and see you on the next topic.
Top comments (0)