OWASP Top 10: Broken Access Control
Access controls are designed to restrict the actions that a user can take on a web application or other system. This includes limiting legitimate users to the access and permissions granted to them and preventing illegitimate users from pretending to be a legitimate user.
In this article
Broken access control vulnerabilities exist when the restrictions and controls are designed or implemented incorrectly. For example, users may be granted access that exceeds what is needed for their role, or an attacker may be able to access a restricted resource by guessing its URL or another user’s unique identifier.
What is the Risk?
Access controls are the foundation of strong cybersecurity. Without the ability to block unauthorized access to sensitive data and functionality, it’s impossible to ensure confidentiality, integrity, and availability.
Broken access controls undermine the security of a web application. If an attacker identifies and exploits these security gaps, they could access and breach sensitive data, perform a denial-of-service (DoS) attack, or take other malicious actions with their illegitimate access.
Examples of Attack Scenarios
Broken access control vulnerabilities can exist in a web application for various reasons. Some of the most common examples include the following:
Improper Authorization
Improper authorization deals with a failure to properly tailor a user’s access to the requirements of their role. For example, an application may take a one-size-fits-all approach to assigning permissions, providing all users with the same level of access. However, this can be dangerous if it means that a user has access to privileged functionality and sensitive information that they don’t need for their role.
URL Manipulation
Some web applications include information about the user and their session in the URL. For example, a user may access their account portal by visiting example.com/user/1234. This may run the risk that an attacker could access other users’ data simply by modifying the URL.
Mass Assignment
Mass assignment vulnerabilities allow user-provided data to be inserted into objects that track data such as the user’s privileges. If this is the case, an attacker may be able to change the values in these objects to grant themselves elevated privileges.
Case Study: First American
In 2019, a vulnerability was discovered in the website of First American Financial Corp, a widely used provider of title insurance. The First American web application used sequential record numbers embedded in URLs to provide users with access to various sensitive documents related to a title transfer. At the time of discovery, over 850 million records dating from 2003 to 2019 were accessible in this way.
This is an example of an access control vulnerability related to URL manipulation because the only parameter used for access control — the record identifier — is embedded in the URL. An attacker who identifies this could iterate through the possible record identifiers, which is easy since they’re sequential, and search for sensitive information for use in identity theft and financial fraud.
How to Remediate Broken Access Control Vulnerabilities
Broken access control vulnerabilities can involve a variety of errors when implementing access controls. Some best practices to address this risk include:
- Implement Least Privilege: Access controls should be defined based on the principle of least privilege, which means that users only have the access that they actually need. Applications should take a “deny by default” approach to designing access controls, and then provide access to resources on an as-needed basis.
- Don’t Use Identifiers for Authentication: Object or user identifiers can be used to identify a particular account but shouldn’t be the sole means of authentication due to the potential that an attacker could learn or guess them. While they can be used for account lookups, they should be paired with another form of access management.
- Centralize Access Control: A common cause of access control errors is having access control decentralized across an application because it makes errors more difficult to detect and updates harder to apply. Access management should be centralized so that everything flows through a single access management module, which is kept secure and up to date.
- Server-Side Access Management: A user has full access to and control over code implemented in client-side code. All access management should be implemented on the server to prevent the client from bypassing it.
- Log Failed Access Attempts: Logs and alerts should be generated any time a user fails to authenticate successfully or tries to access a resource without proper authorization. These could indicate a potential credential stuffing attack, compromised account, or other security risk.
- Implement Rate Limiting: Credential stuffing and password guessing attempts try to defeat authentication by trying various options for a user’s password. Implementing rate limiting for authentication slows these attacks down and decreases their probability of success.
- Limit Session Lifetimes: Web applications commonly use tokens or session identifiers to track a session and avoid requiring a user to reauthenticate for every page that they visit. These should be invalidated when a session ends or have a short lifetime to minimize the potential for theft and misuse.
How IONIX Can Help
The OWASP Top Ten list details the most common vulnerabilities that exist in web applications. While this is intended to help educate developers and enhance security, it also means that these are the security risks that cybercriminals are most likely to look for and exploit.
IONIX helps organizations enhance their security by proactively performing simulated attacks against OWASP Top Ten vulnerabilities when assessing the security risks associated with a web application. To learn more about managing your digital attack surface and threat exposure with the IONIX platform, sign up for a free demo.