Broken Access Control : A comprehensive Introduction

What is it?

Ever thought of doing a banking transaction from another person’s account or booking all the tickets to a movie theatre, all without even being logged in or without having proper credentials for the account? That’s what we call Broken Access Control which basically means that the policies which are kept in the application to moderate the actions of the user are not implemented properly which leads to a potential violation of the policies. Violations may range from unauthorized sensitive information disclosure to gain full access to application functionalities not intended for a normal user. Broken Access Control has been ranked number 1 in the OWASP top 10 lists for 2021

 

Attack Surface

 

IDOR (Insecure Direct Object Reference)

This type of vulnerability allows the attacker to manipulate the request parameters of different application functionalities to gain access to other user’s sensitive information or the information which normally the user is not intended to be served by the application.  Consequences are sensitive information disclosure, modification of other users’ data, user enumeration, etc.

   Example:  https://www.xyz.com/search/Index?key=”payload-here”

   An attacker simply brute forces the request’s ‘key’ parameter to get more results

Privilege Escalation

This type of vulnerability allows the attacker to elevate its permissions, allowing the attacker access to the unintended areas of the application to which the attacker does not have specific permissions to gain access. This type of vulnerability can open attack surfaces such as unauthorized file browsing, sensitive information disclosure, unauthorized data modification, role escalation, etc.

Example: An attacker while browsing through the website founds a hidden page that performs some specific operation, but it didn’t require the user credentials before accessing the functionality.

 

Replay Attack

This type of attack allows the attacker to capture the access control token or session token of an authenticated user and later use the same data to access the application through the captured data by modifying the requests to the application to pretend like the authenticated user and access the application in an unauthorized manner.

Example: An attacker launches a MITM (Man in the middle) attack on a victim and captures the verification token of the session of the user. Later, the attacker uses the same token to access the victim’s account.

 

CORS (Cross-Origin Resource Sharing)

This type of attack surface allows the attacker to use the API (Application Programming Interface) of the application in an unauthorized manner to set up a fraudulent phishing website that mimics the behavior and look of the victim website but with added functionality to capture the credentials of the users of an organization by tricking them into thinking that the application is genuine and same as the original one.

Example: An attacker makes a fake phishing website that mimics the functionality and looks of the original website and is used to capture the credentials of the user. This is made possible by iframe embedding.

 

Examples of Attacks

Scenario #1: The attacker tries to brute-force the parameters of the request for a particular page until it gets one through which it can access the page

 https://www.xyz.com/search/Index?key=”payload-here”

An attacker simply brute forces the request’s ‘key’ parameter

Scenario #2: The application uses unverified data in a SQL call that is accessing account information:

 pstmt.setString(1, request.getParameter("acct"));
 ResultSet results = pstmt.executeQuery( );

Using the browser’s ‘acct’ parameter, the attacker sends whatever account number they want. In the event that the password is not correctly verified, the attacker could access any user’s account.

 https://example.com/app/accountInfo?acct=notmyacct

Scenario #3: An attacker simply forces browses to target URLs. To access the admin page, you must have admin rights.

 https://example.com/app/getappInfo
 https://example.com/app/admin_getappInfo

If an unauthenticated user can access either page or if a non-admin can access the admin page, this is a flaw.

 

What’s the Impact?
 

The impact of the presence of Broken Access Control can be very devastating for organizations as well as an individual because of the reason that the application is not securely handling the requests made due to which vulnerabilities like user enumeration, sensitive information disclosure, information modification, etc. is present which can be exploited by an attacker with motives like exposing sensitive information online, gaining an internal foothold of the network of an organization, modifying information crucial to the organization, etc.

What’s the remediation?

Broken Access Control can be effectively mitigated by implementing access control mechanisms on the server side wherein the attacker cannot craft the access control parameters used by the application nor the attacker does have any access to the mechanisms of access control. Some steps are also listed below to help in mitigation:

  • 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, and 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. To minimize the window of opportunity for an attacker, stateless JWT tokens should be short-lived. In order to revoke access to longer-lived JWTs, it’s highly recommended to follow the OAuth standards.

We discussed about Broken Access control in this blog post and have tried to provide specific knowledge and a deeper grasp of access control, related vulnerabilities, and security threats.

In the following post in this series next week we will focus our attention on A02:2021-Cryptographic Failures. Till then, be secure and check out ASPIA cybersecurity protect services.

Share

Leave a Reply