REST API Security Pentesting Services

API1:2019 Broken Object Level Authorization

“APIs tend to expose endpoints that handle object identifiers, creating a wide attack surface Level Access Control issue. Object-level authorization checks should be considered in every function that accesses a data source using input from the user.”

It is an access control vulnerability that occurs when some input is used to access other resources that they should not have access to. Commonly known as BOLA, almost every organization has APIs vulnerable to BOLA.

Objects are the first things to be considered when creating a program, and they also are the code units that come out of the process. These might be anything, from a customer account to an invoice generated and everything in the process of creating a program. In order to address them directly, these objects are usually labelled with an identifier. This is exactly where problems begin because we must always check if the user has permission to access that object. A broken object issue occurs when a server fails to check the access granted to read, update or delete the objects whose access is not given to the currently logged user.

BOLA is also referred to as Insecure direct object reference (IDOR), which is, a user being able to directly access the resources that he/she does not have access to, using some user functionalities. Most common methods of doing so involves changing an ID parameter where the user can input information. This type of attack takes place as a result of the API not properly checking if the user owns the requested resources or not.

A simple example of this would be an attacker getting access to a company’s customer details by making some random changes to an ID. This can further lead to phishing other social engineering attacks. Therefore, while dealing with a broken object-level authorization a lot of organization data is at stake.

The vulnerabilities are usually found in APIs that use an ID in the request. These could be UserIDs, cookies or URLs, etc. If by changing the ID in the request, a user is able to access resources that he/she did not have access to previously, then a broken object-level authorization has occurred. In order to mitigate this kind of an attack, implementing a user authorization mechanism that checks for a user access resource at every point where user input is subjected can be helpful. Using random, unguessable IDs and checking authorization for clients requesting the access can be some good steps towards preventing broken object-level authorization.

The OWASP API Security Top 10 2019 report mentions that “this has been the most common and impactful attack on APIs”, as it holds great potential for data leakage and data loss.

API3:2019 Excessive Data Exposure

Looking forward to generic implementations, developers tend to expose all object properties without considering their individual sensitivity, relying on clients to perform the data filtering before displaying it to the user.

Although an API is only designed to deliver the required data to front-end clients, it is observed that mistakes are made or easy ways are taken out to implement APIs that return all data to the client. Excessive Data Exposure occurs when these APIs return an excessive amount of data. As a result, and API might return sensitive information such as customer details or user’s personal information.

The reason as to why excessive data exposure takes place is that it provides flexibility during development and allows all the data to be returned once. Considering a quick approach to build and develop APIs, can lead to this common and impactful vulnerability. The data, although is not displayed visually, still exists in the API and an attacker can view all the data sent by an API at the endpoint.

Consider, a web application retrieves information using an API service, then uses the information to display the user’s profile. As a part of the development, application developers assumed that if the information is not displayed on the webpage and users won’t be able to see it. So, they send this entire API response to the user’s browser without filtering the data and rely on the client to filter out sensitive information. Now, besides basic information about the user, this API call also returns the API token, bank account number, location and address of that user. Whereas, for user’s profile, the application only needs to send username and bio. Anyone visiting the profile page will now be able to intercept this API response and get access to user’s personal information. This is an evidence of excessive data exposure.

In order to avoid excessive data exposure, the OWASP suggests to not rely on the client for information filtering, instead the filtering should be done at API level, before the information is sent to the client. This will ensure that the client only receives the information requested by him/her and not extra information is shared. Enforcing response checks to prevent accidental leaks of data and limiting exposure to sensitive information or personally identifiable information can be helpful to avoid the above-mentioned attacks.

API5:2019 Broken Function Level Authorization

Complex access control policies with different hierarchies, groups, and roles, and an unclear separation between administrative and regular functions, tend to lead to authorization flaws. By exploiting these issues, attackers gain access to other users’ resources and/or administrative functions.

The broken function level authorization (BFLA) attacks are similar to BOLA or IDOR attacks. These focus on exploiting the roles and access used in the API.

In the picture given above, we see that there are two individuals, an admin and a user. The access rights to both of them are shown with different colors. In this case, the user was able to exploit the access control system and make changes into the database, here, deleting the user125.

Let us consider a result management system which provides two separate applications for students and teachers. The student app has only one functionality, that is, it only allows a particular student to login and check individual marks. The teacher’s app enables teachers to enter the marks obtained by students for different subjects. Basically, the students have the access to read data while the teachers have access to write and update data. Assuming, a student manages to analyze the mobile app and finds out the API calls for the application, he tries to make a different API call to the access token identified during his analysis. As a result, he is able to make changes in the marks that he had obtained.

What happened in the above example is that higher privilege endpoints were hosted on the same relative path, which made it easier for the student to guess these endpoints and access them.

The access can be made by executing other methods such as a HTTP method or by methods which were left enabled by the developers while the application was being built.

With BFLA, API functions are opposed to objects that APIs interact with as in the case of BOLA. Attackers tend to discover the flaws in API calls as they are structured and quite predictable. They then exploit these flaws by sending API requests to API endpoints whose access is denied or by somehow manipulating API requests generated from legitimate client applications. As a result, attackers exploiting broken function level authorization vulnerabilities can gain access to unauthorized resources, take over another user’s account, perform CURD functions on an account, or escalate privileges to gain administrative access.

API7:2019 Security Misconfiguration

Security misconfiguration is commonly a result of unsecure default configurations, incomplete or ad-hoc configurations, open cloud storage, misconfigured HTTP headers, unnecessary HTTP methods, permissive Cross-Origin resource sharing (CORS), and verbose error messages containing sensitive information.

Misconfiguration vulnerabilities occur when there exists configuration weaknesses or flaws in a software system or component.

Any application can be vulnerable to such an attack there is inappropriate security across any part of the stack or improperly configured permissions on cloud services. These permissions include unnecessary feature that are enabled and permissions which are not required and still have been granted.

In many cases, default accounts are still being used with unchanged passwords. This leads to the possibility of a security misconfiguration attack taking place.

For instance, some sample applications are installed on the application server and are not removed from the production server. These sample applications contain known security issues that attackers can exploit to get access to the server. If the admin console is one of these programs, and default accounts have not been updated, the attacker logs in using default passwords and gains control.

Another example for security misconfiguration attack could be a cloud service provider having default permissions open to the internet. Attackers can gain access to the sensitive data stored within cloud storage.

API9:2019 Improper Assets Management

APIs tend to expose more endpoints than traditional web applications, making proper and updated documentation highly important. Proper hosts and deployed API versions inventory also play an important role to mitigate issues such as deprecated API versions and exposed debug endpoints.

Improper Asset management comes into picture when there are two or more versions of an API present where the new version is in use but the older version has not been discontinued. The vulnerability here is that the older version might be unpatched or might not use the latest security protocols or involve obsolete features for which the documentation makes finding and fixing vulnerabilities difficult. Without the security measures in place, and upgrades not being made to the API, the attacker can bypass them by using known flaws.

Potential consequences of improper asset management include data leaks or server takeover through a common database between the current API and the older one.

To avoid improper asset management, the assets should be managed properly. For that, the older API versions which are not in use should be deleted or discontinued. If these are kept without being used, there is a possibility of these APIs being completely forgotten and not being patched or upgraded on time, which may make them vulnerable to attacks.

OWASP recommends various ways to avoid such attacks. They include making an inventory of all used APIs, and including key information such as the current version, who can access the API, the environment the API is in, and its current point in the life cycle. OWASP also makes an important note: “when newer versions of APIs include security improvements, perform a risk analysis to decide on the mitigation actions required for the older version: for example, whether it is possible to backport the improvements without breaking API compatibility or you need to take the older version out quickly and force all clients to move to the latest version.”

Therefore, improper asset management can be addressed by having proper documentation to explain the purpose of current APIs with information like who can access it, and having strategies that cover the entire design life cycle of the API.