Date: 7th November 2022
Written by: Dan Shallom, Director of Research at OP Innovate.
Unfortunately, I have a long relationship with Broken Access Control (BAC) in most of its forms. As a research leader, I often encounter critical security flaws that have one thing in common – they are all the result of a bad access control design.
BAC is a high-level type of vulnerability that allows threat actors to act outside their originally intended permission set, eventually leading to unauthorized data access/modification.
BAC covers 34 types of vulnerabilities. Here are just a few examples:
In this article, I would like to focus on API security and how it can be compromised with BAC.
According to OWASP, “..94% of applications were tested for some form of broken access control, with an average incidence rate of 3.81%..”
How can we ensure an application is in the 6% that had 0 BAC incidents?
REST API allows users to retrieve information or perform a function for a certain service. REST APIs provide a relatively friendly way of communicating with controllers. A controller consists of endpoints with different designations, although they all belong to the same class. For example, an Account controller allows a user to perform account-level operations by interacting with different endpoints.
Each endpoint has its own functionality. It is implemented inside a handler function. The handler function is called once a user accesses the intended endpoint with the right HTTP method.
Usually, the security controls will have to be implemented inside each handler function.
So, how can unauthorized access enable retrieval or modification of sensitive data? In the following section, I want to share a case study from a client that was vulnerable to Broken Access Control, and how it allowed unauthorized attackers to retrieve lots of PII records containing sensitive information, before our team discovered the issue and notified the client.
When implementing a large number of API controllers with dozens of endpoints, it is a challenge to harden each and every endpoint. This often results in many unsecured endpoints that allow an unauthorized individual to pull/modify data. It is therefore important to manage the whole environment properly.
Here, you can see the getAccountDetails() handler function.
The function should be receiving an email address and returning the associated account information. But as you can see, no check is made to verify whether the requesting party is properly authenticated and authorized, leading to a broken access control issue. An attacker can pull out data for each email address that gets sent to the server. No correlation is made between the requesting party and the email address.
Here, you can see an improved implementation of the same handler function:
This time, the request is sent to a separate function, called “isAuthorized()” that performs authorization checks. The implementation of this function is not shown here, But it will do the following:
Also, you can see that every test is made with exception handling.
Below, I will review recommended action items for both the appsec manager and the developer:
Dan Shallom has worked as a cyber security researcher for the last three years, specializing in web applications, open source security and code review, before transitioning to a Director of Research role that combines both technical and management aspects. He is a CEH and ECSA certified. Dan is also proud to have registered 3 CVEs (CVE-2020-13110; CVE-2021-28860; CVE-2015-20107). Dan joined OP Innovate in March 2019 as a Penetration Tester. He enjoys listening to classic rock and lives in Gedera with his girlfriend.
OP Innovate was established in 2014 to defend global enterprises from the increasing challenges of organizational cybersecurity. Our team has unmatched expertise in cyber research, penetration testing, incident response, training and forensics. Our team members are exposed to cutting-edge responses to today’s most critical cybersecurity concerns allowing us and our partners to remain ahead of the bad guys.