Broken Access Control is an OWASP‘s Top 10 vulnerability category that covers all access control issues that can make your website vulnerable. OWASP is a non-profit organization with the goal of improving the security of software and the internet. We cover their list of the ten most common vulnerabilities one by one in our OWASP Top 10 blog series.
OWASP Top 10 2017 was released in November 2017, bringing some changes to the list from 2013. We are working on updating our content, but in the meantime, please take a look at our article about OWASP Top 10 2017.
Access control is how web applications control what content and functions should be accessible to different users.
For the updated OWASP top 10 list in 2017, Insecure Direct Object Reference and Missing Function Level Access Control were merged into Broken Access Control, creating a broader category including some additions.
Broken Access Control is often a problem with applications that have gradually grown in size. The schemes regulating access were not deliberately designed from the beginning, but are instead something developers have added over time.
In cases where access control is not centralised, this often results in a very complex scheme that is hard to fully understand, which then leads to mistakes and vulnerabilities.
The potential impact of Broken Access Control greatly depends on what kind of information or features the attacker can gain access to. It can be anything from seemingly useless information to a full system takeover.
There are many interesting cases, but to use one as an example, we can take this Hackerone report on a Twitter vulnerability.
By intercepting the request sent to delete his own credit card, the user was able to change the ID of the credit card that was going to be deleted, and by doing so delete an account that was not his. This could have resulted in a halted campaign and, consequently, a considerable business advantage.
Please see the report above for more details as we only cover it as proof that these vulnerabilities do exist in the wild.
How to discover
One way to discover Broken Access Control is to browse the website while logged in and log all pages visited. The next step is then to log out and revisit all pages. If content that should only be available to logged-in users is shown on these pages, the website is vulnerable. Some proxies made for security testing support this type of analysis by default, though manual intervention is needed to confirm whether the page/information is indeed sensitive.
Another way to discover Broken Access Control is to simply bruteforce different paths. An example would be /admin, /settings or similar that only an admin should be allowed to visit. If any user can access those, this would be considered a vulnerability. This is also called forced browsing, – in simplified terms, enumerating and accessing resources that are not referenced by the application, but are still accessible.
Yet another way to do this is to identify user IDs and similar data in requests and simply change them to something else. Chances are that information about some other user can be received that way, or even the ability to execute actions in their name. That would be similar to the Twitter vulnerability mentioned above in Well-known events.
How Detectify can help
Some of the examples covered under this category cannot be found with automated tools, but at the same time, many of the vulnerabilities in this category can be detected by a vulnerability scanner like Detectify.
Detectify will, for example, test a range of pages that should only be accessible to administrators and see if anyone can access them, as well as look for applications used that have known vulnerabilities related to this. Sign up for a free trial to find out if you are vulnerable »
Detecting and taking advantage of this vulnerability is considered easy. Often, all it takes is for the attacker to attempt a specific action that should require authentication and if the request succeeds, the page is considered vulnerable. What is hard to do here is to figure out every page that is at risk and know exactly which features could potentially lead to something dangerous.
When a user accesses the dashboard on their bank’s website, they get redirected to the following URL:
In this case, 123 is the ID of the user’s account, and the user will therefore see that balance. If the user wanted to abuse this, it would be possible to just change the URL parameter to someone else’s ID and instead get access to that ID’s account.
This is just one of the many examples that fall under this category, and is much more common than you might imagine.
The default should always be denial. Everyone should be denied access to everything, and then every specific role can be explicitly granted access for each function needed. It is recommended to log failed attempts to access features to make sure everything is configured correctly.