What is access control?
Access control is the application constraints on who or what is authorized to perform actions or access resources. In the context of web applications, access control is dependent on authentication and session management:
- Authentication confirms that the user is who they say they are.
- Session management identifies which subsequent HTTP request are being made by that same user.
- Access control determines whether the user is allowed to carry out the action that they are attempting to perform.
Broken access control are common and often present a critical security vulnerability. Design and management of access controls is a complex dynamic problem that applies business, organizational, and legal constraints to a technical implementation. Access control design decisions have to be made by humans so the potential for errors is high.
Vertical access controls
Vertical access controls are mechanisms that restrict access to sensitive functionality to specific types of users. With vertical access controls, different types of users have access to different application functions. For example, an administrator might be able to modify or delete any user’s account, while an ordinary user has no access to these actions. Vertical access controls can be more fine-grained implementations of security models designed to enforce business policies such as separation of duties and least privilege.
Horizontal access controls
Horizontal access controls are mechanisms that restrict access to resources to specific users. With horizontal access controls, different users have access to a subset of resources of the same type. For example, a banking application will allow a user to view transactions and make payments from their own accounts, but not the accounts of any other user.
Context-dependent access controls
Context-dependent access controls restrict access to functionality and resource based upon the state of the application or the user’s interaction with it. Context-dependent access controls prevent a user performing actions in the wrong order. For example, a retail website might prevent users from modifying the contents of their shopping cart after they made payment.
Example of broken access controls
Broken access control vulnerabilities exist when a user can access resources or perform actions that they are not supposed to be able to.
Vertical privilege escalation
If a user can gain access to functionality that they are not permitted to access then this is vertical privilege escalation. For example, if a non-administrative user can gain access to an admin page where they can delete user accounts, then this is vertical privilege escalation.
Unprotected functionality
At its most basic, vertical privilege escalation arises where an application does not enforce any protection for sensitive functionality. For example, administrative functions might be linked from an administrator’s welcome page but from a user’s welcome page. However, a user might be able to access the administrative functions by browsing to the relevant admin URL. For example, a website might host sensitive functionality at the following URL:
https://insecure-website.com/admin
This might be accessible by any user, not only administrative users who have a link to the functionality in their user interface. In some cases, the administrative URL might be disclosed in other locations, such as the robots.txt file:
https://insecure-website.com/robots.txt
Even if the URL isn’t disclosed anywhere, an Attacker may be able to use a wordlist to brute-force the location of the sensitive functionality.
LAB:
unprotected admin functionality(writeup not yet published)
In some cases, sensitive functionality is concealed by giving it a less predictable URL. This is an example of so-called “security obscurity”. However, hiding sensitive functionality does not provide effective access control because users might discover the obfuscated URL in a number of ways. Imagine an application that hosts administrative functions at the following URL:
https://insecure-website.com/administrator-panel-yb556
This might not be directly guessable by an Attacker. However, the application might still leak the URL to users. The URL might be disclosed in JavaScript that constructs the user interface based on the user’s role:
<script>
var isAdmin = false;
if (isAdmin) {
...
var adminPanelTag = document.createElement('a');
adminPanelTag.setAttribute('href', 'https://insecure-website.com/administrator-panel-yb556');
adminPanelTag.innerText = 'Admin panel';
...
}
</script>This script adds a link to the user’s UI if they are an admin user. However, the script containing the URL is visible to all users regardless of their role.
LAB:
unprotected admin functionality with unpredictable URL(writeup not yet published)
Parameter-based access control methods Some applications determine the user’s access right or role at login, and then store this information in a user-controllable location. This could be:
- A hidden field.
- A cookie.
- A preset query string paremeter.
The application makes access control decisions based on the submitted value. For example:
https://insecure-website.com/login/home.jsp?admin=true
https://insecure-website.com/login/home.jsp?role=1
This approach is insecure because a user can modify the value and access functionality they’re not authorized to, such as administrative functions.