Broken Access Control in REST APIs – Shields Up 🛡️ !

Date: 7th November 2022

Written by: Dan Shallom, Director of Research at OP Innovate. 

TL;DR

1. Broken Access Control (BAC) & Coverage
2. An underrated and dangerous vulnerability that affects us all
3. REST APIs as a Case Study
   1. Mitigation
   2. SSDLC tips
4. About OP Innovate

Overview & Coverage

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: 

• Path Traversal (CWE-22)
• Cross-Site Request Forgery (CWE-352)
• URL Redirection to Untrusted Site (CWE-601)
• Exposure of Information Through Directory Listing (CWE-548) and more. 

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 APIs in a nutshell

REST API allows users to retrieve information or perform a function for a certain service. They 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, implemented in a handler function. This 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.

REST APIs – Unauthorized Access 

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:

• Make sure all inputs are properly sanitized before passing them over to other functions.
• Extract the authorization identifier and check whether the requesting party has an active valid session
• Check whether the requesting party has permission to receive data from this endpoint.
• Check whether the email address supplied in the body of the request matches the one of the requesting party, so that a user will not be able to get information from other users.

Also, you can see that every test is made with exception handling.

Recommendations

Below, I will review recommended action items for both the appsec manager and the developer:

• AppSec Manager
  • Penetration Testing
    • Even if the request is constructed on the client side with an authorization header or a token, it does not necessarily mean that the server will perform a security checkup. Try to send the request without the authorization identifier and see if it is still possible to get information back from the server.
    • Try to get information belonging to other users – manipulate the request parameters and change their values.
  • Code Review
    • Review the implementation of handler functions and make sure that Role-based/Permission-Based access control checks are made.
    • Make sure all API endpoints and their associated HTTP methods are supposed to be in the production environment. Developers sometimes leave certain routes for testing purposes in production environments. No efforts are made to assure they are securely implemented, since they’re not even supposed to be there.

• Developer
  • Properly map each and every API endpoint, and make sure that authorization is properly made, by assuring that:
    • The requested party is known to the application
    • The requested party has permissions to access the requested endpoint
    • The requested data is associated with the requested party
  • Make sure that the publicly accessible resources/functionalities are intended to be open for all.
  • Properly configure CORS (Cross-Origin Resource Sharing) protocol.
  • Use exception handling in order to avoid leaking stack traces with sensitive information.
  • Set a rational expiration time for session tokens.
  • Expire tokens when they are superseded by a new token.

Takeaways

• Statistically speaking, it is like that you are vulnerable to some form of Broken Access Control. Create a good Application Security design in order to prevent this issue from adversely impacting your application.
• Broken access control issues are sometimes overlooked, leading to critical impacts in many cases.
• The design phase of REST APIs is significant; developers should put more effort in it. Security checks should be widely implemented on every controller.

—

About The Author 

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.

About Us

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.