In today’s world, it is possible to see APIs everywhere, and it’s not surprising that such a widely used architecture can have security vulnerabilities, right? Let’s take a look at the well-known OWASP API TOP 10 list and discuss how we can overcome these vulnerabilities with the Apinizer.
Before we start the discussion, let’s take a quick look at the API Gateway architecture in order to understand how we can intervene with Apinizer in a logical framework.
As we can see, the API Gateway is positioned in the middle of the client and the backend API. This way, access to the APIs is done through a single point, which allows applications and users to only perform specific and permitted operations, thus increasing the security of the APIs. Additionally, the API Gateway provides benefits such as traffic management, security, authentication and authorization, scaling, monitoring and analytics, routing and mediation, caching, and transformation.
With this basic architecture in mind, we can now delve into how Apinizer can provide solutions to the risks on the OWASP API TOP 10 list.
Otherwise known as an Insecure Direct Object Reference (IDOR) attack, Broken Object Level Authorization vulnerability can be summarized as a user being able to access information of an object they do not have authorization for. This occurs when authorization is inadequate or absent.
Countermeasures that can be taken:
Apinizer can perform “Authorization.” Authorization provides an additional layer of security after identity verification. The addition of authorization allows us to return an error message flow, if the roles the user has do not match the roles expected by the method/endpoint, and to continue the message flow if the user’s roles match the roles expected by the method/endpoint, thus preventing “Broken Object Level Authorization” vulnerabilities.
This vulnerability involves problems with user information that arises from the improper use of authentication functions or brute force attacks.
Summing up in a few points:
Countermeasures that can be taken:
It is essential to install an authentication mechanism for our APIs. We can use the following policies from Apinizer: “Plain-Text Authentication,” “Basic (Base64) Authentication,” “Digest Authentication,” “OAuth2,” “JWT Authentication” in order to complete this step.
Token validation and “expires” time can be completed without coding requirements by using the “OAuth2” and “JWT” policy settings.
To prevent brute force attacks, we can use the “API Based Throttling&Quota” policy to set limits on APIs based on days, hours, or months. We can also use the “Allowed IP List” policy to open our APIs to specific IPs if requests are coming from specific IP blocks. Another option is to use Credential-based Throttling and Quota to limit the number of requests that can be made from a single user, IP or application.
Typically, APIs assume that information will be restricted on a UI basis and can therefore transmit all information in the response. For example, consider an API that returns student information, which can transmit the student’s name, surname, school number, phone, and other information. However, in the application, only the name or a narrowed down piece of information may be desired. The API, however, returns the whole object, and therefore a vulnerability arises. An attacker could use a proxy to intervene and obtain all unfiltered information.
Countermeasures that can be taken:
Apinizer, as an API gateway product, can filter the message internally before returning it to the client, only returning the necessary information in the response. This filter can be applied using “JSON Transformation,” “XML Transformation,” and “Script” policies, and in addition, using the “Redaction” policy, customizing the response based on any header, parameter, or body field or their values of the message coming from the Backend API.
To better understand the process described above, let’s construct a scenario together; Let’s say we have an API service for a hospital, and this API service returns data from three clinics in the message and these data include information on General Surgery, Eye Diseases, and Dental Clinics in their respective sections in the body. Assume that the general surgery clinic makes a request to our service using specially created credential information. In this case, the general surgery clinic will view the data of the other two clinics in the response. Using the “Redaction” policy, we can delete or edit the data of the other two sections based on the credential information.
When making API calls, there must always be a request limit. If no limit is present, an attacker could make a lot of calls in order to exhaust server resources and potentially cause our API services to fail to respond, or even cause a delay. For example, if we have an SMS API, an attacker could send a large number of messages in a short period of time, which could exhaust the resources of our SMS provider and cause a delay in the delivery of messages to our legitimate clients.
Countermeasures that can be taken:
Apinizer provides “API-based Throttling&Quota” and “Credential-based Throttling&Quota” policies to ensure that the number of requests is limited based on time, IP addresses, or specific user accounts. “API-based Throttling&Quota” policy sets limit to number of requests on a per API basis. “Credential-based Throttling&Quota” policy sets limit based on the user accounts, IP addresses, or specific application making requests. Additionally, “Throttling” policy can be used to limit the rate of requests to a specific number of requests per minute, hour, or day. These policies can also be used to prevent DDoS attacks.
This vulnerability can occur in large-scale applications that have specific roles and boundaries that these roles can access. When authorization is not properly controlled, this vulnerability can occur. For example, a normal user may access admin-level methods due to faulty or missing authorization controls.
Countermeasures that can be taken:
As stated in the beginning of the article, Apinizer can create specific roles with Authentication process and assign boundaries to those roles in order to prevent this vulnerability from occurring.
The core concept of the “Mass Assignment” vulnerability is that data received from an API is matched to our database or class without performing any control operations. To give an example, let’s say we have a database that contains username, password, and role fields. Our scenario requires us to take username and password and give the role field a default value of 0. But, what if the user sends a malicious request and sends the role parameter with a value of “1” ? The user now grants themselves admin status.
Countermeasures that can be taken:
To prevent this vulnerability, Apinizer has a Schema Validation feature. By using the “JSON Schema Validation” and “XML Schema Validation” policies, we can limit the message content, or by using the “Business Rule” policy, we can validate specific rules on the request or response message and prevent this vulnerability.
According to OWASP, one of the most common security vulnerabilities is security misconfiguration. This vulnerability can be caused by incorrect configuration of service settings or their absence. It can also stem from outdated systems, missing or non-existent security systems, and files or directories. Another option is that security misconfiguration vulnerability can arise when various errors are made, such as considering all systems trustworthy in “CORS” configuration.
Countermeasures that can be taken:
In addition, CORS settings can easily be adjusted through Apinizer. There are many other reasons why this vulnerability can occur, we recommend researching the “Security Misconfiguration” vulnerability in detail.
Injection is a broad category of vulnerability, and there are several types such as SQL, LDAP, NoSQL, OS Command, etc. Injection can be summarized as interference with the query through query strings. In APIs, the goal of attackers is to write queries such as query continuation with query strings in the parameter values.
Countermeasures that can be taken:
To prevent injection attacks, the values sent must be filtered according to certain criteria. By filtering according to the types of attacks, injection attacks can be prevented. In Apinizer, there are “Filter Rules” that contain default filters for basic injections. These filters can also be customized and extended.
This vulnerability is primarily based on the test environment, many security tests are performed on the live environment, but test environments may not be as secure as the production environment. For example, error messages may not be filtered in the test environment. Therefore, attackers may target test environments.
Countermeasures that can be taken:
The most important step in preventing this vulnerability is to limit access to the test environment to only authorized personnel who perform test tasks, i.e., by creating IP restrictions or credentials, a test environment can be created that can only be accessed by certain users, and many attacks can be prevented in this way. With the “Allowed IP List” policy in Apinizer, only IPs that are allowed to access the test environment can access the API, and this attack can be largely prevented.
Attackers can take advantage of lack of logging and monitoring to carry out their targeted operations without being detected for a long time. Our service must absolutely perform logging and monitoring operations and be able to take quick action in certain situations.
Countermeasures to be Taken;
Here, Apinizer comes into play, it logs everything about API traffic, it records all the data, including the original data and the manipulated data, if any, coming from the client via Apinizer. Another advantage of Apinizer is that by using the “Anomaly Detector by Query” in the monitoring area, logs can be made sensitive to certain anomalies, and instant action such as receiving an email can be taken in case of certain events. In addition to these, in the API Traffic tab on Apinizer, detailed log monitoring opportunities are available, where you can see which user requested the traffic, what method (get, post, etc.) they used, or how long it took to receive a response.
In conclusion, Apinizer offers all the necessary tools and features to help developers comply with OWASP API Security Top 10 recommendations, performs all the necessary steps for creating a secure API automatically, and allows developers to focus only on the important applications.
Input your search keywords and press Enter.