OWASP’s New #1 Threat for 2021 — Broken Access Control
A Brief Analysis by Haseeb Aslam.
OWASP TOP 10
Overview of New Top 10
The Open Web Application Security Project (OWASP) has released the 2021 Top 10 list of most common web application vulnerabilities. There are some major changes to the list this year than the last release of 2017. The diagram below illustrates the changes and new additions to the list.
One of the biggest change is the new number one, Broken Access Control, moving up from number five in last full release. The previous number one vulnerability was injection which has moved down to number 3. Another big change worth mentioning is the reorganization of last release’s number three spot, Sensitive Data Exposure, to Cryptographic Failures which is the number two spot on the latest release.
Recent OWASP Top 10 Changes and Additions
“There are three new categories, four categories with naming and scoping changes, and some consolidation in the Top 10 for 2021. We’ve changed names when necessary to focus on the root cause over the symptom.”
A new addition at number four is Insecure Design, mostly focusing on architectural flaws and can be broadly described as “missing or ineffective control design.” Important to note OSWAP differentiates “between insecure design and ‘insecure implementation” as the new number 5 spot is Security Misconfiguration, referring to “Missing appropriate security hardening across any part of the application stack or improperly configured permissions on cloud services.”
The number 6 spot belongs to Vulnerable and Outdated Components, previously referred to Using Components with Known Vulnerabilities, up from number nine in 2017. The “increased availability of standardized frameworks” has moved the 2017 number 2, Broken Authentication, down to number 7 and has been renamed to Identification and Authentication Failures. Another new addition to the list, Software and Data integrity Failures, which include 2017’s number 8 spot, Insecure Deserialization, due its broad definition that includes “assumptions related to software updated, critical data, and CI/CD pipelines without verifying Integrity”.
Making a small move up from 2017’s number 10, Insufficient Logging & Monitoring, to 2021’s number 9 as Security Logging and Monitoring Failures. This particular vulnerability is difficult to test, with the exception of host-based logging solutions such as Splunk, that usually have plugins in scanning tools like Tenable’s Nessus (speaking from experience as a past Splunk and Tenable.sc Administrator). The final spot was given to Server-Side Request Forgery, due to security community members expressing concerns even though OWASP’s data doesn’t indicate the concern it raised earning the top spot from the Top 10 community survey.
Broken Access Control
Overview of New #1 Vulnerability — Broken Access Control
The Dutch programmer and physicist, Wieste Venema, had some thoughts on access controls when referring to his creation, the TCP wrapper, as “an example of such a safety net. I wrote it when my systems were under attack by someone who appeared to walk through walls”. The TCP wrapper solved many access control issues at the network layer for Unix based systems however the application layer is a much more complex beast and requires the broad categorization of OSWAP’s 2021 number one application vulnerability, Broken Access Controls.
The main purpose of any access control system is to ensure “that users cannot act outside of their intended permissions”. Unfortunately, SAST and DAST tools do not provide the ability to verify whether access controls are functional in production, only detect the absence of them in the code.
These vulnerabilities “lead to unauthorized information disclosure, modification, or destruction of all data or performing a business function outside the user’s limits”.
Maybe it is as simple as the illustration below suggests:
Technical Examples of Broken Access Controls
The reality of failing to properly implement such a fundamental aspect of security leads a hacker’s wet dream and the worst nightmares of security professionals. Because authentication and authorization are paramount for any kind of secure communication on the internet, their importance cannot be overstated. However time and time again, there are instances like engineers or developers leaving unencrypted S3 buckets with valuable data open to the public internet. Without proper access control implementation, you might as well leave the front door open for the bad guys to walk in.
The list of common access control vulnerabilities provided by OSWAP include:
· Violation of the principle of least privilege or deny by default, where access should only be granted for particular capabilities, roles, or users, but is available to anyone.
· Bypassing access control checks by modifying the URL (parameter tampering or force browsing), internal application state, or the HTML page, or by using an attack tool modifying API requests.
· Permitting viewing or editing someone else’s account, by providing its unique identifier (insecure direct object references)
· Accessing API with missing access controls for POST, PUT and DELETE.
· Elevation of privilege. Acting as a user without being logged in or acting as an admin when logged in as a user.
· Metadata manipulation, such as replaying or tampering with a JSON Web Token (JWT) access control token, or a cookie or hidden field manipulated to elevate privileges or abusing JWT invalidation.
· CORS misconfiguration allows API access from unauthorized/untrusted origins.
· Force browsing to authenticated pages as an unauthenticated user or to privileged pages as a standard user.
How to Prevent Broken Access Controls
The solution is not as easy as the illustration on the last page suggest, “fix authentication and authorization”, but rather the solution is unique in each case. One of the main attack vectors is to modify the request received by the servers so the proper way is to enforce the access control “in trusted server-side code or server-less API, where the attacker cannot modify the access control check or metadata”. It is strongly recommended that “Developers and QA staff should include functional access control unit and integration tests”.
OWASP suggest the following general preventative measure:
· 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.
· 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.
· 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 highly recommended to follow the OAuth standards to revoke access.
Attack Vectors and Scenarios
Scenario 1: Application Uses Unverified Data
The attacker in this scenario uses unverified in a SQL query that access account information of users:
pstmt.setString(1, request.getParameter(“acct”));
ResultSet results = pstmt.executeQuery();Because the application is not validating the data input by the user, the attacker could modify the query and possibly access any account on the database. By changing the “acct” parameter in the query and without proper input validation, the server would execute the query and return the account information based on the parameter. Example below showing the URL with a modified “acct” parameter that does not belong to the user:
http://example.com/app/accountInfo?acct=notmyacctScenario 2: Attacker Forces Browser to Target URL
The application in the example does not require the proper authentication and thus no authorization of the request coming to the admin interface for the system. A normal URL to a page containing application information might look like this (should not be able this either):
http://example.com/app/getappInfoThe attacker in this scenario could change the URL to include the term “admin” (depending on the architecture of the application) in the directory path like shown below:
http://example.com/app/admin_getappInfoThe application should not allow an unauthenticated user to access the admin page, this is a serious security flaw as the attacker has access to an admin functionality that could lead to much larger security event.
Conclusion
The 2021 OWASP is only in its first edition and the future changes will hopefully shed more light into the issues surrounding Broken Access Control. The impact of not taking access control seriously could lead to “attackers acting as users or administrators, or users using privileged functions, or creating, accessing, updating or deleting every record”. The operation impact of such an events would be subjective to the specific case however it certainly won’t be positive.
References:
· https://owasp.org/Top10/A00_2021_Introduction/
· https://owasp.org/Top10/A01_2021-Broken_Access_Control/
· https://owasp.org/www-project-top-ten/2017/A5_2017-Broken_Access_Control
· https://medium.com/@shivam_bathla/a01-2021-broken-access-control-c458f8a1f4e2
· https://hdivsecurity.com/owasp-broken-access-control
· https://www.azquotes.com/author/15044-Wietse_Venema
