OWASP-Access Control Vulnerability
This article is going to focus on Access control security and Broken Access control, it will summarize the thoughts, procedures and describe privilege escalation that arises due to Access Control vulnerability and how to mitigate them.
The Access control vulnerability is ranked among the highest by the OWASP Top 10, so it becomes a necessity to understand it and the possible ways to detect it when you go on your next bug hunt.
So grab your snacks, water to keep hydrated, and anything to note, because this article is going to be long and interesting.
WHAT IS ACCESS CONTROL?
Access control or authorization is the constraint that tells the user who or what can be accessed in an application.
So we can say that in the context of the web application the access control depends upon authorization and session management.
Session Management- It is used to check the subsequent HTTP request are made by the same user.
Authentication- Verify the identity of the user
Access Control- Verify the action performed by the user, is allowable or not.
So designing and implementing the Access control is a complex process, because they differ for every web application. From a user perspective, access control can be divided into the following categories:
- VERTICAL ACCESS CONTROL -
Vertical access control is the mechanism that restricts the access to sensitive functionality from a group of users. For example in a web application administrator has the right to modify the user accounts, while a normal user does not enjoy this privilege.
2. HORIZONTAL ACCESS CONTROL-
Horizontal access control is the mechanism that allows a group of people to use a particular resource that is explicitly assigned to them. For example, in a banking system, you can only view and modify your account not others.
3. CONTEXT-DEPEND ACCESS CONTROL-
These types of access control restrict the functionality based upon the state of the application or how users is interacting with it. A very common example of this is that any e-commerce website might prevent users from modifying the prices of a commodity while shopping.
BROKEN ACCESS CONTROL
So this vulnerability exists when a user can access the resource which is forbidden for them.
(I) VERTICAL PRIVILEGE ESCALATION
Access the functionality which is not permitted for them
[I.I] Unprotected Functionality -
This is the most basic type of vertical privilege escalation, where an application does not enforce any kind of protection to access sensitive information.
For instance, if a user can access the admin panel directly by modifying the URL.
https://xyz.com/admin
This kind of information can be accessed or we can say leaked by checking out the robots.txt.
In some cases, the information is not leaked directly but still can be accessed by some other means, as they are not much robustly protected but merely concealed for a less predictable URL, this is called security by obscurity.
For an instance, the admin panel URL can be leaked by analyzing the javascript code that constructs the user interface based upon the user role.
<script>
var isAdmin = false;
if (isAdmin) {
…
var adminPanelTag = document.createElement(‘a’);
adminPanelTag.setAttribute(‘https://xyz.com/admin');
adminPanelTag.innerText = ‘Admin panel’;
…
}
</script>
So the above script does a simple action, it links the user UI if the user is an admin, and the URL it contains is visible to all regardless of the state of the user.
[I.II] Parameter Based Access Control Method-
More frequently web applications used another method to recognize the role of the user, for which they store the information regarding the user during the time of logging in. This piece of info could be in any controllable location such as cookies, hidden fields, or preset query string parameters.
https://xyz.com/login/frame.jsp?admin=true
https://xyz.com/login/frame.jsp?role=1
For example, this web application understands the role of the user by checking the required field. This approach is dangerous as users can manually alter these fields and grant admin access.
[I.III] Platform Misconfiguration-
This one is quite interesting. Sometimes what happens, is that web applications enforce certain access control to specific URLs and HTTP-based requests based on the profile of the user. For eg:
DENY: POST, /admin/modify, regular
The above-described rule denies the POST method to the /admin/modify, for the users in the regular group. To bypass this we can use various non-standard HTTP headers, which can override the URL original request, for instance, we can use X-Original-URL and X-Rewrite-URL. So if the web application allows URL to be overridden via a request header this trick will work.
For example, if the web application specifies the above rule we just need to add a single line, using the proxy server (Burpsuite).
POST / HTTP 1.1
X-Original-URL: /admin/modify
The other type of attack that is available in this arsenal is the method-based attack, as the above-described one is URL-based. In this attacker can use GET(or some other method) to circumvent the access control.
(II) HORIZONTAL PRIVILEGE ESCALATION
As already discussed this vulnerability arises when a user gains access to the resources which belong to somebody else (a.k.a. Stealing).
Some of the exploits under this category are similar to vertical privilege escalation. To have a better understanding let’s take a simple analogy, there are two users (Bob and Alice)of a famous e-commerce website. When Bob access his account he notice that the id parameter is changed to a particular value which looks like this
http://xyz.com/myaccount?id=100
Now, if he modifies the id parameter by supplying the arbitrary value, he can access somebody else accounts, in this case, he passes the value ‘101’ and accesses the Alice account.
Well, always the vulnerability is not going to be this straight, as many applications do not have a predictable value. For this, they prefer using GUID (Global Unique Identifier), in this case, guessing will not work. However, the GUID of another user can be hidden or leaked somewhere in the application, for instance, we can check wherever that particular user is referenced.
A horizontal privilege escalation attack can be converted into a vertical privilege escalation attack, if the attacker is somehow able to compromise the account of a more privileged user, all of the above-described attacks can result in this.
(III) INSECURE DIRECT OBJECT REFERENCES
So IDOR is a type of access control vulnerability that arises when an application uses user-supplied input directly to access objects. These are most closely related to horizontal privilege escalation, but in some cases, they can also arise in vertical escalation.
(IV) ACCESS CONTROL VULNERABILITY IN MULTI-STEP PROCESS
Some web applications implement important functions over a series of steps, like when we have multiple inputs or options that we need to be provided before confirming a certain action.
For instance, a web application has certain steps:
A user form
Submit the changes
Review the changes
So a web application might have rigorous access control over some steps, but ignore others in this case, if there are control methods for steps 1,2, by assuming the fact that the user will reach the final step only when the first two are completed. Bypassing this can lead to an attacker gaining unauthorized access to the application.
(V) REFERER-BASED ACCESS CONTROL
The web application has the referer header which is generally added to the request to indicate and find the page from which the request was initiated. Some of the access-control are based upon the Referer header submitted in the HTTP request.
For example, an application enforces the access control over the admin page ‘/admin’, but for sub-pages ‘/admin/modify’ they only inspect the Referer header so if the referer header contains ‘/admin’ then it will allow the access. This can be exploited by attackers as the sub-pages can be directly manipulated
HOW TO PREVENT ACCESS CONTROL VULNERABILITY
Finally, in the last section where we will discuss how to prevent and mitigate this vulnerability. The following approach can be used:-
- Never depend upon the obfuscation alone for access control.
- Reduce the usage of public access resources, until required explicitly.
- Mostly use a single-wide application mechanism for the entire application.
- Thoroughly audit and test access control to make sure that they are working as desired
Keep on hunting and securing the web for a better and safe place!!
Follow me on medium and LinkedIn for such articles.
