Mitigating OWASP Top 10 API Security Threats with an API Gateway — Part 3

Broken Function Level Authorization, Mass Assignment, and Security Misconfiguration

Figure 1: It is critical to configure security of your APIs correctly to avoid leaving gaping back-doors for attackers to feast on

This article is part of a series aimed at bringing awareness to OWASP Top 10 Security Threats and how they can easily be mitigated using a good API Gateway.

Read Part 1 and Part 2 if you missed it.

Here we will focus on another 3 threats from the list: Broken Function Level Authorization, Mass Assignment, and Security Misconfiguration.

5 — Broken Function Level Authorization

Many modern API-based applications have APIs with multiple resources to perform various tasks, thereby increasing the need for proper authorization checks while taking into account the user hierarchy. Lack thereof will result in attackers being able to access important and sensitive functionality and information only available for authorized users. Administrative functions are the key targets for this type of attack.

An example of the exploitation of such a vulnerability could involve an application that uses the endpoint:

/company/v1/users/{user_id}

where {user_id} is replaced with the respective user’s ID and by using the GET method, returns a JSON with details about that particular user’s profile.

However, if an attacker notices a pattern in the way the APIs in the application is structured, the attacker may be able to duplicate the request and manipulate the HTTP method to DELETE which is the endpoint for deleting existing users. In this application, that specific endpoint does not implement function-level authorization / access privilege checks, therefore the attacker is able to delete an existing user profile and carry out potentially harmful actions on the system as illustrated below (Figure 2).

Figure 2: Attacker deletes an existing user account

In other words, the attacker is able to send legitimate API calls to existing API endpoints that they must not have access to.

Most of the time, the main targets of this type of attack are API endpoints that perform administrative functions, which further signifies the importance of implementing proper authorization mechanisms in any application.

How can this be mitigated?

First, it is essential to review and perform a comprehensive analysis of the current authorization mechanism in an application if any while taking into account the user hierarchy and all the different roles, permissions and groups in the application.

It would be ideal if the following 3 questions can be answered in order to clearly distinguish the pitfalls of the current authorization mechanism:

1. Is it possible for a regular user with basic permissions to access administrative APIs or functions?
2. Does changing the HTTP method of an endpoint allow a user with basic permissions to perform sensitive actions (i.e. administrative actions like creation, modification and deletion of data)?
3. Can a user from one user group access a functionality that must only be exposed to users from another user group, by just guessing the endpoint URL and parameters?

OAuth scope-based access control functionality in an API Gateway can be used to easily mitigate this vulnerability. Once the OAuth token is received from the user, the Gateway can validate it against a Security Token Service (STS) before allowing the request to pass through to the backend as shown below (Figure 3).

Figure 3: Attacker attempts to call the POST endpoint with an OAuth token that has a mismatching scope but the API Gateway thwarts it easily

In this case, an attacker is trying to access the DELETE endpoint /company/v1/users/10 to delete an existing user with user id 10 by using an OAuth token Nhtifireofghewl34jd43i which has the scope of misc-staff (i.e. a normal user without administrative privileges) in this application. However, the Gateway placed in between the attacker and the backend will validate the OAuth token with the Security Token Service to identify whether the scope is of an administrator. Since it isn’t the Gateway will abort the request being sent to the backend and return a 403 Forbidden error.

On the other hand, this will be how a legitimate request would look like with the API Gateway in place:

Figure 4: A legitimate client attempts to call the same POST endpoint but with an OAuth token which has the right scope

The client will access the same POST endpoint but this time with the OAuth token T842m0wnfsliewqieew which has the scope of admin (user with administrative privileges). Since the Security Token Service validates and confirms that this token has a scope of admin, the Gateway will allow the request to pass through to the backend and the respective response will be given back to the client successfully.

6 — Mass Assignment

Many modern API-based applications contain objects that have a large number of properties, of which only a few should be updated directly by a client, such as a user’s first name, last name, and address in the case of a user profile. However, there are also properties that should not be edited by a client, such as permission-related properties that are set only by admins, and internal properties that should only be set internally, such as the creation time of an item. If these properties are identified by an attacker, it could lead to privilege escalation, data tampering and even worse, bypassing stringent security mechanisms.

An example of exploitation of this type of vulnerability could involve an online payment application allowing the user to edit basic information for their profile. The API endpoint:

application/v1/users/{user_id}

with the HTTP method PUT allows for this and the attacker could send the usual payload like the one below for example:

{ “first_name”: “Allan”, “last_name”: “Trousdale”, “DOB”: “1/12/1979” }

It will return the updated user profile along with an additional property to signify the balance of the particular user in the JSONObject (shown in Figure 5).

{ “username”: “allant01”, “first_name”: “Allan”, “last_name”: “Trousdale”, “DOB”: “1/12/1979”, “balance”: 0 }

Figure 5: An attacker running a normal API call to the PUT endpoint and finding out that a property that signifies the balance of the user is accessible by this API

By just replaying the PUT request with the following payload, the attacker is then able to mass assign properties that should not be edited, which in this case is the balance property:

{ “first_name”: “Allan”, “last_name”: “Trousdale”, “DOB”: “1/12/1979”, “balance”: 9999999999 }

Figure 6: The attacker taking advantage of the vulnerability in the API that allows anyone to change the balance amount of a user.

How can this be mitigated?

Firstly, it is essential to identify and assess the existing APIs in an application which allows properties to be updated directly by the client by automatically converting client parameters to internal object parameters without taking into account the sensitivity of those properties.

Examples of these properties include:

• internal properties like created time or updated time
• process-dependent properties like credit balance
• permission related properties like is_admin

Once this process is completed an API Gateway will mitigate this vulnerability by screening all API requests that contain parameters that are defined as sensitive and should only be changed internally from the application and bounce back those requests with a meaningful error message.

Figure 7: API Gateway rejecting an attempt by the attacker to change the sensitive parameter of balance

Furthermore, an API Gateway is also capable of screening parameters passed in an API request by scope. For example, a member of the security team could require whitelisting a device for Allan. This is made possible via a PUT request to the endpoint /application/v1/users/{user-id}/activities, and a property called whitelist_ip_address. However, with an API Gateway in place, it would accept requests containing that property in the payload only if the scope is either security_team or admin (shown in Figure 8).

Figure 8: Scope-based Access Control in an API Gateway being used to screen API request payload

7 — Security Misconfiguration

Prying attackers will often try to find unpatched flaws, hidden endpoints, or inadequately protected files or directories to obtain unauthorized access or gain insight into the inner workings of the system. The main issue with this type of vulnerability is that it could occur at any point in the API stack.

This type of vulnerability could occur due to the following main weaknesses:

• The latest security patches are missing.
• Unused features are enabled.
• The Transport Layer Security is missing.
• Security Headers are not sent to clients.
• The CORS policy is improperly set or does not exist.
• Error messages with stack traces that include sensitive information.

A scenario where this type of vulnerability could be exploited is when Cross-Origin Resource Sharing (CORS) is not configured in the most optimal way. For example, the GET endpoint /company/v1/users/12 does not restrict invocations to any specific domain (Access-Control-Allow-Origin: * — which is usually the default value). Therefore, keeping some hacker back-doors such as around Cross-Site Request Forgery (CSRF) open for attackers to take advantage of (shown in Figure 9).

Figure 9: Attacker exploiting ability to invoke API from a suspicious domain due to improper configuration of CORS policy

How can this be mitigated?

Modern API Gateway solutions are already well equipped to deal with this type of vulnerability. Make sure the solution being used allows for extensive customization of properties such as:

• CORS configuration (including setting up the Access Control Allow headers and methods).
• Transport Level Security (especially HTTPS, TLS and SSL)
• Application Level Security (OAuth 2.0, Basic Authentication, API Key)
• Response Caching

In-depth explanation of what these properties are and different ways they can be configured is out of the scope of this article and best left to be discussed separately.

Let me know in the comments below if you would like to see articles on the same :).

However, having as many configuration options as possible in an API Gateway and using them correctly will go a long way in pro-actively preventing exploitation of this vulnerability.

Taking CORS configuration as an example, it could be configured in an API Gateway such that only approved domains are allowed to access the API instead of allowing all domains (i.e. Access-Control-Allow-Origin: *).

Figure 10: Correct configuration of CORS policy in API Gateway will restrict API invocations to trusted applications

As shown by Figure 10, an attacker trying to invoke the API from the domain pentesting.com will be denied access to the resource by the API Gateway after it validates the configured list of allowed origins and the origin of any given invocation.

In this article you went through an in-depth analysis of the 5th, 6th and 7th threat on the OWASP Top 10 Threats list and how they can easily be mitigated using an API Gateway.

Stay tuned for 4th and final part of the Mitigating OWASP Top 10 Threats with an API Gateway article series by following me and the API Integration Essentials publication here on Medium where you can learn about the rest of the threats on the list and see how an API Gateway can help you eliminate them for good!

Update: You can now read Part 4 over here.