A01: Broken Access Control

>Control Description

Maintaining its position at #1 in the Top Ten, 100% of the applications tested were found to have some form of broken access control. Notable CWEs included are *CWE-200: Exposure of Sensitive Information to an Unauthorized Actor*, *CWE-201: Exposure of Sensitive Information Through Sent Data*, *CWE-918 Server-Side Request Forgery (SSRF)*, and *CWE-352: Cross-Site Request Forgery (CSRF)*. This category has the highest number of occurrences in the contributed data, and second highest number of related CVEs. 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 the user's limits. Common access control vulnerabilities include: * Violation of the principle of least privilege, commonly known as 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 that modifies API requests. * Permitting viewing or editing someone else's account by providing its unique identifier (insecure direct object references) * An accessible API with missing access controls for POST, PUT, and DELETE. * Elevation of privilege. Acting as a user without being logged in or or gaining privileges beyond those expected of the logged in user (e.g. admin access). * Metadata manipulation, such as replaying or tampering with a JSON Web Token (JWT) access control token, a cookie or hidden field manipulated to elevate privileges, or abusing JWT invalidation. * CORS misconfiguration allows API access from unauthorized or untrusted origins. * Force browsing (guessing URLs) to authenticated pages as an unauthenticated user or to privileged pages as a standard user.

>Prevention & Mitigation Strategies

1.Except for public resources, deny by default.
2.Implement access control mechanisms once and reuse them throughout the application, including minimizing Cross-Origin Resource Sharing (CORS) usage.
3.Model access controls should enforce record ownership rather than allowing users to create, read, update, or delete any record.
4.Unique application business limit requirements should be enforced by domain models.
5.Disable web server directory listing and ensure file metadata (e.g., .git) and backup files are not present within web roots.
6.Log access control failures, alert admins when appropriate (e.g., repeated failures).
7.Implement rate limits on API and controller access to minimize the harm from automated attack tooling.
8.Stateful session identifiers should be invalidated on the server after logout. Stateless JWT tokens should be short-lived to minimize the window of opportunity for an attacker. For longer-lived JWTs, consider using refresh tokens and following OAuth standards to revoke access.
9.Use well-established toolkits or patterns that provide simple, declarative access controls.

>Attack Scenarios

#1Unverified SQL parameter tampering

The application uses unverified data in an SQL call that is accessing account information: ``` pstmt.setString(1, request.getParameter("acct")); ResultSet results = pstmt.executeQuery( ); ``` An attacker can simply modify the browser's 'acct' parameter to send any desired account number. If not correctly verified, the attacker can access any user's account. ``` https://example.com/app/accountInfo?acct=notmyacct ```

#2Forced URL browsing to admin pages

An attacker simply forces browsers to target URLs. Admin rights are required for access to the admin page. ``` https://example.com/app/getappInfo https://example.com/app/admin_getappInfo ``` If an unauthenticated user can access either page, it's a flaw. If a non-admin can access the admin page, this is a flaw.

#3Client-side-only access control bypass

An application puts all of their access control in their front-end. While the attacker cannot get to `https://example.com/app/admin_getappInfo` due to JavaScript code running in the browser, they can simply execute: ``` $ curl https://example.com/app/admin_getappInfo ``` from the command line.

A01—Broken Access Control

>Control Description

>Prevention & Mitigation Strategies

>Attack Scenarios

>Related CWEs

>References

Ask AI