Update: Broken Access Control is proposed to be number one on the new OWASP Top 10 list of 2021. The group found that 94% of web apps tested were vulnerable to this, justifying the push up to #1.
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.
Description
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.
Prevalence
Broken Access Control is often a problem that emerges in applications that have gradually grown in size. Instead of deliberately designing schemes regulating access from the beginning, developers have added them over time.
In cases where access control is not centralised, this often results in a very complex scheme that is hard to fully understand. A complex scheme, in turn, leads to mistakes and vulnerabilities.
Potential impact
The potential impact of Broken Access Control greatly depends on what kind of information or features the attacker can gain access to. This can be anything from seemingly useless information to a full system takeover.
Well-known events
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. By doing so, he could delete an account that did not belong to him. 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 Broken Access Control
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 can still be accessed.
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 you can receive information about another user or even execute actions in their name. This 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. At the same time, a vulnerability scanner like Detectify can discover many Broken Access Control vulnerabilities.
Detectify will, for example, test a range of pages only administrators should be able to access and see if anyone can access them. The scanner also looks for applications that have known vulnerabilities related to Broken Access Control. Sign up for a free trial to find out if you are vulnerable »
Exploitability
Detecting and taking advantage of this vulnerability is easy. Often, all it takes is for the attacker to attempt a specific action that should require authentication. 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.
Example
When a user accesses the dashboard on their bank’s website, they are redirected to the following URL:
https://bank/balance?acc=123
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, they could 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.
Remediation
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.