About
Broken access control refers to vulnerabilities related to user authorization. It indicates that restrictions are not applied correctly to what an authenticated user can do.
Last updated
Broken access control refers to vulnerabilities related to user authorization. It indicates that restrictions are not applied correctly to what an authenticated user can do.
Last updated
OWASP has merged “Insecure Direct Object References” and “Missing Functional Level Access Control” into “Broken Access Control” - a universal catch-all for various kinds of access control vulnerabilities previously addressed individually on the OWASP Top 10: 2013 list.
Websites require permissions for users and must have an administrator who can allow or deny certain privileges to others. When operating correctly, access control (or authorization) grants access to content and functions to some users, denying it to others. However, application access policies can be “broken” when developers misconfigured functional-level access, resulting in flaws or gaps that deny access to legitimate users or permit them to act outside of their intended permissions. This typically leads to unauthorized access, information disclosure, modification or destruction of data, the performance of a business function that differs from its intended use, or even take-over site administration.
From a user perspective, access controls can be divided into the following categories:
horizontal access controls
vertical access controls
context-dependent access controls
Broken access control is a widespread threat that is easy to discover and exploit.
Broken Access Control should be viewed in connection with Broken Authentication.
In the context of web applications, access control is dependent on authentication and session management:
Authentication identifies the user and confirms that they are who they say they are.
Session management identifies which that same user is making subsequent HTTP requests.
Authorization checks are performed after authentication. When a user visits a web page, first, they must log in to authenticate themselves. Then if they try to gain access to a resource, the server verifies if they are authorized to do so and determines whether the user can carry out the action attempting to perform.
Therefore, this vulnerability happens when the application fails to properly validate authorization after the user has been authenticated.
All known web or application servers and web application environments are susceptible to at least some access control issues.
Broken access control occurs from insecure coding or insecure implementation of authentication and authorization mechanisms. Achieving a secure access control mechanism may seem simple, but it can promptly become complicated. Web application’s access control model is firmly attached to the content and functions that the site provides, and developers often underrate the need for consistency, resulting in ad-hoc rules throughout the code, which becomes so unwieldy that it is nearly impossible to understand. Even if a site is entirely static, hackers could gain access to sensitive files and deface the site or perform other attacks, if the site is not configured correctly. Besides, various users may form many groups or roles with different privileges, further complicating the system.
Access control weaknesses are usually not detectable by dynamic vulnerability scanning and automated static source-code review tools as they require an understanding of how certain pieces of data are used within the web application. Therefore, manual testing is the most reliable way to detect missing or insufficient access control. Nonetheless, these vulnerabilities are not too difficult to spot. Often all that is needed is to craft a request for functions or content that should not be granted.
All sites have some access control requirements. Therefore, you need a well-documented access control policy to clarify what should be considered broken access control. Also, the design documentation should capture an approach for implementing this policy. If this documentation does not exist, a site is likely to be vulnerable.
The detailed review of the code that implements the access control policy should reveal some of the vulnerabilities. Besides, penetration testing can help determine if there are problems in the access control scheme.
SAST and DAST tools can detect the inadequacy of access control but cannot verify if it is efficient when it is present.
These weaknesses are common due to the lack of automated detection and effective functional testing by application developers.
Broken access controls can leave applications at a high-risk for compromise, typically resulting in the impact of confidentiality and integrity of data. The consequences can be devastating.
The technical impact is attackers acting as users or administrators; unauthorized users accessing privileged functions; creating, accessing, updating, or deleting contents; or gaining full control over web applications. Further attacks against the web server and infrastructure may be possible.
The business impact depends on the protection needs of the application and data.
To reduce the risks of broken access control:
Apply the most limited privileged concepts – employ a role appropriate to the task and only for the time necessary to complete tasks.
Delete accounts you no longer require.
Audit servers and websites.
Disable access points until they are needed to reduce your access windows.
Apply multi-factor authentication to all access points.
Remove unnecessary services off the server.
Check externally accessible applications versus applications that are attached to your network.
Access control is only efficient if enforced in trusted server-side code or server-less API, where the attacker cannot modify the access control check or metadata.
The most significant step is to examine through an application’s access control requirements and capture it in a web application security policy. To determine a proper methodology for restricting access control, OWASP recommends doing a risk assessment, and from there, implement an access control policy.
Since this vulnerability usually occurs from insecure coding, the access control mechanism should be extensively tested to be sure that there is no way to bypass it.
The technical recommendations by OWASP to prevent broken access control are:
Except for public resources, deny access to functionality by default.
Implement access control mechanisms once and reuse them throughout the application, including minimizing CORS usage.
Model access controls should enforce record ownership, rather than accepting that the user can create, read, update, or delete any record.
Domain models should enforce unique application business limit requirements.
Disable webserver directory listing and ensure file metadata (e.g., git) and backup files are not present within web roots.
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.
JWT tokens should be invalidated on the server after logout.
Developers and QA staff should include functional access control units and integration tests.
For administrative functions, the first suggestion is not to allow administrator access through the front door of the site. If remote administrator access is needed, VPN technology could be used to give outside administrator access to the internal company (or site) network from which an administrator can then access the site through a protected backend connection.
Frequent access control vulnerabilities include:
Bypassing access control checks by modifying the URL, internal application state, or the HTML page, or using a custom API attack tool.
Allowing the primary key to be changed to another's user's record, permitting viewing or editing someone else's account.
Elevation of privilege. Acting as a user without being logged in or acting as an admin when logged in as a user.
o horizontal privilege escalation: when a user can perform an action or access data of another user with the same level of permissions;
o vertical privilege escalation: when a user can perform an action or access data that requires a level of access beyond their role.
Metadata manipulation, such as replaying or tampering with a JWT access control token, a cookie, or hidden field manipulated to elevate privileges or abusing JWT invalidation.
CORS misconfiguration grants unauthorized API access.
Force browsing to authenticated pages as an unauthenticated user or privileged pages as a standard user. Accessing API with missing access controls for POST, PUT, and DELETE.
More examples available here.
In 2019 the insurance and real estate closing services provider First American Financial Corp suffered a breach of up to 885 million customer records because of a flaw in its public cloud. Bank account information, mortgage statements, tax records, driver’s license information, and wire transaction history were accessible to practically anyone with a browser. Anyone with a document link could retrieve the files, requiring no validation or verification of identity and providing no access control.
API that powered informed visibility service in The United States Postal Service (USPS) had a flaw that unintentionally allowed any logged-in user to view, and in some cases, modify, account details of other users. Anyone using a browser could manipulate the quest with minimum effort. An estimated 60 million customers’ data was exposed. The breach could have been easily prevented if the API had done an access check to see if the individual making the request had the proper authorization.
Toyota Motor Corporation has been the victim of a series of data breaches in Australia, Thailand, Vietnam, and Japan, affecting the personal information of as many as 3.1 million customers.
At least 20 million US citizens have been impacted by the security incident, in which the hacker stole user data, including names, Social Security numbers, addresses, dates of birth, and payment card information from the American Medical Collection Agency. The company has been unable to determine precisely what data has been compromised and had to pay out over $3.8 million to inform over seven million people who have potentially been impacted, resulting in a filed request for bankruptcy protection. Furthermore, multiple class-action lawsuits were. Victims claim that there was an unnecessary delay in informing victims, HIPAA standards may not have been met, and there was a lack of adequate security in place to protect their personal information.
DoorDash confirmed that unauthorized third-party accessed data on 4.9 million users.
Telecommunications giant T-Mobile suffered a security breach that impacted prepaid customers.
____________________________________________________________________________________________
References:
[1] OWASP
[2] HDIVSECURITY
[3] PortSwigger
[4] ContrastSecurity
[5] TheHackerish
[6] Sucuri
