Missing Function Level Access Control is one of the vulnerabilities on OWASP’s Top 10 list and occurs when authentication checks in request handlers are insufficient. A proof of concept video follows this article. OWASP is a non-profit organization with the goal of improving the security of software and the internet. Detectify covers their list of the ten most common vulnerabilities one by one in a OWASP Top 10 blog series. OWASP Top 10 2017 was released in November 2017, bringing some changes to the list from 2013.
Description
If the authentication check in sensitive request handlers is insufficient or non-existent the vulnerability can be categorised as Missing Function Level Access Control.
An example of this would be an unauthorised user being able to access a URL that contains any sensitive information or exposes functionality intended only for authorized users. Another example of a common type of this vulnerability would be to simply hide a feature from the user, but allowing the request if the user is able to figure out how to conduct it. An example of the latter can be found under the title Code Example in this article.
In some ways this category of vulnerabilities is very similar to IDOR that we have previously written about. To simplify, it can be said that the difference is that IDOR exposes information by going to a URL that an ordinary user should not know about, while this category involves vulnerabilities that expose functionality rather than information. Missing Function Level Access Control vulnerabilities can also require more from the attacker than enumerating a URL.
Prevalence
When OWASP devised their list of the most important vulnerabilities in 2010, this vulnerability was listed as uncommon. Three years later, in 2013, the status had changed to common and it had at the same time jumped up a step on the OWASP Top 10 list.
From our experience we can tell that this is a vulnerability that affects websites and companies of all sizes. However, bigger ones seem to be more seriously affected due to the complexity of their systems.
Potential impact of Missing Function Level Access Control
As with many of the vulnerabilities taken up in the series, the potential impact of Missing Function Level 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. When this vulnerability is discussed it is usually vulnerabilities with the impact somewhere in between.
To concretize the impact, the following comparison can be made: It is often possible to execute actions under other regular users’ names without touching anything related to admins.
Exploitability
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 or feature that could potentially lead to anything dangerous.
As with every other vulnerability, there are instances where Missing Function Level Access Control is really hard to exploit and sometimes it is just part of a chain attack that requires a great amount of creativity, but such cases are exceptions rather than the rule.
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, 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 Missing Function Level Access Control is to browse the website while logged in and log all pages visited. The next step is to log out and then revisit all pages. If you get the same result, it is likely that this vulnerability exists. Some proxies made for security testing support this type of analysis by default.
Another way is to simply bruteforce different paths. An example may be /admin, /settings or similar that only an admin should be allowed to visit. If any user can access these, it would be considered a vulnerability. This is also called forced browsing, which, simplified, is to enumerate and access resources that are not referenced by the application, but are still accessible.
Yet another way is to identify user IDs and similar data in requests and simply change them to someone 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.
If you carry out a code analysis, the pattern where a privileged request is processed can be identified, making it easier to understand how the authorization pattern works. This way, it is possible to discover places where the same process is not applied, but the request is still considered sensitive.
How Detectify can help
We provide a quick and easy way to check whether your site passes or fails OWASP Top 10 tests. Detectify is a web security scanner that performs fully automated tests to identify security issues on your website. It tests your website for over 700 vulnerabilities, including OWASP Top 10, and can be used on both staging and production environments. Sign up for a free trial to find out if you are vulnerable »
Code example of vulnerable application
A simple mockup application has been created to better explain one of the many ways this vulnerability may occur.
Dashboard.php
This page presents a form where the user enters an order ID and then chooses the action, the alternatives being Cancel and Status. If a logged in admin visits the page, the alternative Return is available as well. The request is then sent to action.php.
Action.php
This page takes the order ID and the chosen action and then executes the action towards the order. It does not employ any authentication or check to see that the user is an admin as that has already been done by dashboard.php.
The problem here is that if the attacker can figure out that the alternative Return does exist, but is hidden for non-admins, a request to action.php can still be sent, returning the payment. The impact in this case would be that the attacker could order free stuff from the web shop we set up as an example, as the payment could be refunded after each purchase.
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. It is also recommended to log all failed attempts as that can help discover if something is incorrectly configured.
Blocking all file types that should not be served anyway is a great way to prevent an attacker from accessing any forgotten configuration files, databases or log files that were mistakenly exposed to the internet without authorisation. Enforcing such blocking may not always be possible, but it is good to at least consider it.
Do NOT, under any circumstance, assume that the users are unaware of special/hidden URLs or APIs. That is a misconception that we see way too often, and as clearly shown in our code example, this is not enough. Doing so is called security through obscurity and we greatly discourage you to rely on it.
Missing Function Level Access Control Proof of Concept video:
Read more
More on the Detectify blog:
Additional OWASP:
Missing Function Level Access Control
Failure to Restrict URL Access
Forced browsing