OWASP Top Ten Series: Missing Function Level Access Control

Missing Function Level Access Control

What is the vulnerability?

Web applications typically only show functionality that a user has the need for and rights to use in the UI on screen. For example, if someone works in a hospital, but doesn’t have the rights to view health records, then this functionality is not presented to them. But what if a link to see such records was known to them? Or what if the function to show the health records was in the web page code delivered to their browser, but just hidden in the UI. It’s possible that a user could spoof the URL to invoke the health records display function if they know how to do that, or they could view the HTML and JavaScript code of a page to see how to call the function. If they do this and they can get access to parts of the application that they shouldn’t then this is a case of Missing Function Level Access Controls.

Another possibility to consider is whether a user of a web application can directly browse to a resource that provides access to functionality they shouldn’t see. For example, adding a different User ID number to a URL to gain access to a colleague’s settings page, or changing it to be an admin user ID and getting access to privileged admin functions. If you have been reading our previous OWASP posts you might be thinking how is this vulnerability different from an Insecure Direct Object Reference vulnerability ? The latter type of vulnerability provides direct unauthorised access to data and information. Whereas a Missing Function Level Access Control vulnerability provides unauthorised access to functionality in a web application. Note the subtle difference between these. In most situations the outcome will be the same. Both will provide unauthorised access to data or information that shouldn’t be shown. Often leading to the same consequences such as identity theft of users whose information is exposed, financial loss to both users and the organisation. Also, the organisation that failed to protect the information can experience reputational damage, financial penalties, contractual disadvantages and a loss of trust in their brand and messaging.

How to protect against Missing Function Level Access Control vulnerabilities

All of the advice given in the previous Insecure Direct Object Reference post is also relevant when protecting against Missing Function Level Access Control vulnerabilities. In addition to the advice outlined in the previous post, the points in the list below should be considered in order to help protect against this type of vulnerability.

• It is highly recommended to always apply a deny-by-default rule. Disallow access to all functions in the app by default, then allow access only to those users and other parts of the application that need it.

• Even when access to functions within a web application are allowed, each request needs to be verified at the time of the access. Check that the requests are from valid authorised users.

• Use access control lists and role based authentication to enforce the above. Use the principle of least privilege. To emphasise – give access to functions only if required. Don’t try and give general access and then remove access rights from users who shouldn’t have it.

• Don’t try to rely on security by obscurity by just hiding buttons and links to functionality within the UI. Someone will stumble upon a way to access the hidden functions. Plus, people who are determined to attack your web application will ignore the UI and send requests directly in order to try and get responses from the backend application and database engines.

• Check every URL, button, and other way to access functions in your web application using an account with low privileges. See if these accounts can get access to functions they shouldn’t. There are tools that can help with this task. They compare scans of your web applications when authenticated as an Admin user, with scans when authenticated as standard users. They then highlight parts of the application that are available to standard users when they shouldn’t be.

• The OWASP site has several Cheat Sheets that detail procedures for properly configuring access controls. In addition the KEMP Web Application Firewall Pack (AFP) for LoadMaster includes tools that continuously monitor traffic and requests to application and web servers. AFP detects and counters known vulnerabilities, including those outlined by OWASP. The AFP pack is updated constantly by KEMP security experts so that vulnerabilities system administrators may not have heard about are countered.