Rushing Labs

A01:2021 Broken Access Control


Access control is all about making sure a user cannot act outside of their intended permissions. Or in other words, make sure a user can't do what they aren't supposed to do.

Common vulnerabilities in this category look like§

  • Violation of principle of least privilege (i.e. deny by default)
    • Access should only be granted for particular users, roles, capabilities but it's open to anyone
  • Bypassing access control checks by modifying the URL (i.e. parameter tampering)
    • Also, via modifying application state, HTML page, or some attack tool to modify API requests
  • Viewing, editing other user accounts by providing unique identifiers (insecure direct object references)
  • API access with missing access controls for POST, PUT and DELETE
  • Elevation of privilege
    • Ex: Act as user without being logged on
  • Metadata manipulation
    • Abusing JWT invalidation, replaying/tampering with a JWT, or some other access control token or cookie
  • CORS misconfiguration allowing API access from unauthorized/untrusted origins
  • Force browsing to authenticated pages as unauthenticated user (or to privileged pages as standard user)

Defensive Design & Prevention§

  • 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 highy recommended to follow the OAuth standards to revoke access. lived JWTs it's highy recommended to follow the OAuth standards to revoke access.