Broken Access Controls & IDOR: Access control vulnerabilities and privilege escalation

 Access control design decisions have to be made by humans, not technology, and the potential for errors is high.

What is Access control:

Access control (or authorization) is the application of constraints on who (or what) can perform attempted actions or access resources that they have requested.

Access controls can be divided into the following categories:

• Vertical access controls
• Horizontal access controls
• Context-dependent access controls

Vertical access controls:

An administrator might be able to modify or delete any user’s account, while an ordinary user has no access to these actions.

Horizontal access controls:

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 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 have made payment.

WHAT IS Broken Access Controls:

Broken access control vulnerabilities exist when a user can in fact access some resource or perform some action that they are not supposed to be able to access.

Vertical privilege escalation:

If a non-administrative user can in fact gain access to an admin page where they can delete user accounts, then this is vertical privilege escalation.

Example, a normal user can access admin page just by changing the URL to /administrator-panel page:

https://0a8600e803137697837c01d000f10080.web-security-academy.net/

Due to the broken access control a normal user was able to access admin page and perform unauthorized actions.

Broken access control resulting from platform misconfiguration

Some applications enforce access controls at the platform layer by restricting access to specific URLs and HTTP methods based on the user’s role. For example an application might configure rules like the following:

DENY: POST, /admin/deleteUser, managers

This rule denies access to the POST method on the URL /admin/deleteUser, for users in the managers group.

Some application frameworks support various non-standard HTTP headers that can be used to override the URL in the original request, such as X-Original-URL and X-Rewrite-URL.

X-Original-URL and X-Rewrite-URL are HTTP request headers that are used to preserve or modify the original URL of a request.

Now lets delete the user using this vulnerability:

curl -X POST ‘https://0a93009604ee22e582b84cb9001c0013.web-security-academy.net/?username=wiener' -H ‘X-Original-Url:/admin/delete’

X-Original-URL is a header that is commonly used by web servers and reverse proxies to preserve the original URL of a request that has been rewritten or redirected. This header is typically used when the server or proxy rewrites the URL to point to a different location or resource but wants to preserve the original URL for logging or debugging purposes

Method-based access control can be circumvented

Suppose a web application allows a user to update their profile information using a POST request. The front-end restricts access to this action based on the HTTP method used in the request.

However, if the attacker sends a GET request to the same URL, the server may still update the user’s profile information, allowing the attacker to bypass the access control restrictions.

Now the user role upgraded to admin privileges.

You may encounter discrepancies in whether /admin/deleteUser and /admin/deleteUser/ are treated as distinct endpoints. In this case, you may be able to bypass access controls simply by appending a trailing slash to the path.

A request to /ADMIN/DELETEUSER may still be mapped to the same /admin/deleteUser endpoint but treated as distinct endpoints.

Horizontal privilege escalation

Horizontal privilege escalation is a type of security vulnerability that occurs when an attacker gains access to resources or functionality that they are not authorized to access within the same privilege level as their own account.

For example, suppose a web application allows users to access their own data stored in a database. If an attacker finds a vulnerability in the application that allows them to access data belonging to other users with the same level of access, they can exploit this vulnerability to escalate their privileges and gain access to sensitive information or functionality that they are not authorized to access.

A user might ordinarily access their own account page using a URL like the following:

https://insecure-website.com/myaccount?id=123

Now, if an attacker modifies the id parameter value to that of another user, then the attacker might gain access to another user's account page, with associated data and functions.

Horizontal privilege escalation can occur due to various reasons such as improper session management, insufficient authorization checks, or predictable resource identifiers.

User ID controlled by request parameter, with unpredictable user IDs:

If an attacker modifies the id parameter value to that of another user, then the attacker might gain access to another user's account page, with associated data and functions.

Here, the application uses globally unique identifiers (GUIDs) to identify users.

However, the GUIDs belonging to other users might be disclosed elsewhere in the application where users are referenced, such as user messages or reviews.Here it is referenced in the post.

We can use this to access the user Carlos's account.

User ID controlled by request parameter with data leakage in redirect:

In some cases, an application does detect when the user is not permitted to access the resource, and returns a redirect to the login page. However, the response containing the redirect might still include some sensitive data belonging to the targeted user, so the attack is still successful.

Here, I am logged in as weinerthen tried to change my id to carlos

This request redirected me to the login page but when I intersepted the traffic the redirect response leaked the user carlos API key

Insecure direct object references (IDOR)

Insecure direct object references (IDOR) are a type of access control vulnerability that arises when an application uses user-supplied input to access objects directly.

Example:

IDOR vulnerability with direct reference to static files

In the live chat feature of this application there is an option to download the chat

When I intercepted the traffic I noticed that each time I download the file the number increments, what if I forge this number to 1.txt

Then it downloads another users chat:

CONNECTED: - Now chatting with Hal Pline - 
You: Hi Hal, I think I've forgotten my password and need confirmation that I've got the right one
Hal Pline: Sure, no problem, you seem like a nice guy. Just tell me your password and I'll confirm whether it's correct or not.
You: Wow you're so nice, thanks. I've heard from other people that you can be a right ****
Hal Pline: Takes one to know one
You: Ok so my password is 45fbyz7v2ytfzj56mcrc. Is that right?
Hal Pline: Yes it is!
You: Ok thanks, bye!

→And we got the password of another user.

Access control vulnerabilities in multi-step processes with no access control on one step

This is how the admin panel looks like, there is an option to upgrade or downgrade the user privileges:

1. Load form containing details for a specific user.
2. Submit changes.

3. Review the changes and confirm.

Sometimes, a web site will implement rigorous access controls over some of these steps, but ignore others.Suppose access controls are correctly applied to the first and second steps, but not to the third step assuming that a user will only reach step 3 if they have already completed the first steps.

Vulnerability:

What if the attacker gain unauthorized access to the review function by skipping the first two steps:

POST /admin-roles HTTP/2
Host: 0a94001d047616e182650617009000f8.web-security-academy.net
Cookie: session=p9ygpnXNmopXpjjNxjLvZsabC16sfzuL
.......
Sec-Fetch-Site: same-origin
Sec-Fetch-User: ?1

action=upgrade&confirmed=true&username=weiner

⚡adithyakrishna ❯❯ curl  -v -X POST -H 'Cookie: session=HgPUgit5FzaMh4erw70p5iu3vNW57UDT' -d 'username=wiener&confirmed=true&action=upgrade' https://0a94001d047616e182650617009000f8.web-security-academy.net/admin-roles

The site didn't check if the session belonged to the administrator due to this vulnerability, a normal user was able to upgrade the privileges.

Referer-based access control

The Referer header is generally added to requests by browsers to indicate the page from which a request was initiated.The Referer header can be spoofed or manipulated by attackers. An attacker can modify the Referer header to make it appear as if the request is coming from an approved domain or IP address, thus bypassing the access control mechanism.

Vulnerability:

Suppose an application enforces access control over the main admin page at /admin, but for sub-pages such as /admin/admin-rolesonly inspects the Referer header. If the Referer header contains the main /admin URL, then the request is allowed.

⚡adithyakrishna ❯❯ curl  -v -X POST -H 'Cookie: session=2KLql4eoHvUTIF05hZceRyjq27MA2Nx0' -d 'username=wiener&action=upgrade' -H 'Referer: https://0ad7008a03267a718220ab6300770073.web-security-academy.net/admin' https://0ad7008a03267a718220ab6300770073.web-security-academy.net/admin-roles

• The curl command you provided is sending an HTTP POST request to the URL “https://0ad7008a03267a718220ab6300770073.web-security-academy.net/admin-roles".
• “-v” — verbose mode, which displays additional information about the request and response
• “-X POST” — specifies that the request should be sent using the HTTP POST method
• “-H ‘Cookie: session=2KLql4eoHvUTIF05hZceRyjq27MA2Nx0’” — sets the session cookie for the request to “2KLql4eoHvUTIF05hZceRyjq27MA2Nx0”
• “-d ‘username=wiener&action=upgrade’” — sets the request body to “username=wiener&action=upgrade”, which is encoded as application/x-www-form-urlencoded data
• “-H ‘Referer: https://0ad7008a03267a718220ab6300770073.web-security-academy.net/admin'" — sets the Referer header to “https://0ad7008a03267a718220ab6300770073.web-security-academy.net/admin"

Wiener now has admin privileges:

Access control vulnerabilities can be prevented by implementing the following best practices:

1. Use a principle of least privilege: Ensure that users have only the minimum level of access necessary to perform their tasks. This can reduce the impact of a potential attack if an account is compromised.
2. Implement strong authentication: Use secure authentication mechanisms such as multi-factor authentication (MFA), strong passwords, and password policies to ensure that only authorized users can access resources.
3. Use authorization mechanisms: Implement role-based access control (RBAC), attribute-based access control (ABAC), or other access control mechanisms to restrict access to sensitive resources.
4. Regularly review and update access control policies to ensure they are working as designed: Conduct regular reviews of access control policies to ensure they are up-to-date and effective. Policies should be adjusted as necessary to respond to changes in the environment or threats.
5. Wherever possible, use a single application-wide mechanism for enforcing access controls.
6. At the code level, make it mandatory for developers to declare the access that is allowed for each resource, and deny access by default.
7. Implement security logging and monitoring: Collect and analyze security events to detect potential access control violations or suspicious activity.
8. Train users on security best practices: Educate users on security best practices such as password hygiene, phishing prevention, and safe browsing to reduce the risk of accidental or intentional security breaches.
9. Unless a resource is intended to be publicly accessible, deny access by default.