An API (Application Programming Interface) is an interface that allows you to build on the data and functionalities of another application while providing tools, routines and protocols for developers building software applications and also enabling the user to extract and share data in an accessible manner. While the API provides you with an interface where you can enhance the functionalities of another application, it is the web service which is a network-based resource that actually fulfils the task. Hence an API can either be online or offline. However, the APIs that use web services as a resource to fulfil a specific task, are termed as Web service APIs. REST API security testing (also called as REST API VAPT) is imperative to ensure data security of the web application.
A web service is a software system which has been designed to support interoperable machine-to-machine interaction over a network. It provides an interface described in machine-processable format such as WSDL (Web Services Description Language) so that other systems interact with the web service in a manner prescribed by its description using SOAP messages typically conveyed using HTTP with an XML serialization in conjunction with other web related standards. Simplifying, we can say that the Web APIs send data back and forth using HTTP requests which are often returned with textual data in form of JSON or XML response. Since web services APIs expose the application's data and functionalities over the internet, it is essential to review their security.
SOAP (Simple Object Access Protocol) and REST (Representational State Transfer) are two popular approaches for implementing APIs.
SOAP has built-in WS-Security standard which uses XML Encryption, XML Signature and SAML tokens to deal with transactional messaging security considerations. SOAP also supports OASIS and W3C recommendations. It's built-in standards and envelope-style of payload transport requires more overhead compared to other API implementations, such as REST. However, organizations requiring more comprehensive security and compliance may benefit from using SOAP.
REST uses HTTP to obtain data and performs operations on remote computer systems. It supports SSL authentication and HTTPS to achieve secure communication. REST uses JSON standard for consuming payloads thus simplifying data transfer over browsers. REST is stateless where each HTTP request contains all necessary information, meaning that neither the client nor the server are required to retain any data to satisfy the request. Unlike SOAP, which requires parsing and routing for each request to function on a local web service, REST leverages standard HTTP requests and does not require the repackaging of data.
APIs often self-document information regarding their implementation and internal structure, which is widely used as intelligence for cyber-attacks. Additionally, vulnerabilities such as weak authentication, lack of encryption, flaws in the business logic and insecure endpoints make APIs vulnerable to the attacks mentioned below.
App security isn't a feature or a benefit - it is a bare necessity. One breach could cost your company not just millions of dollars but a lifetime of trust. That is why security should be a priority from the moment you start writing the first line of code.
“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.
Authentication mechanisms are often implemented incorrectly, allowing attackers to compromise authentication tokens or to exploit implementation flaws to assume other user’s identities temporarily or permanently. Compromising a system’s ability to identify the client/user, compromises API security overall.
Broken authentication is a common term in the OWASP Top 10. When talking about broken authentication, there are several vulnerabilities which attackers try to exploit in order to gain advantage. An attacker can carry out session management attacks like stealing tokens during session hijacking. This, ultimately results into Broken authentication.
Whenever and API endpoint that handles authentication is discovered, it is recommended to be extra vigilant as these endpoints can determine the user control flow and data accessed throughout the application. If an API allows credential stuffing, an attacker can try to brute force credentials by using a list of known user IDs and passwords that are retrieved from other websites. These attacks are very common, as individuals often re-use their account names and passwords on multiple websites. If these credentials are leaked in anyway, a lot of user accounts are vulnerable. Attackers may use these credentials on the API endpoints to check if any of them work and gets the attacker access to the application.
Broken Authentication is caused due to poor design and implementation of access controls. Many of the worst data breaches in recent years have been caused by broken authentication attacks.
Password recovery techniques, for example, frequently send an SMS to a user's phone containing a reset token consisting of a series of numbers. If the API does not provide rate limitation, an attacker can guess and try to enumerate the password reset token through a thousand of distinct combinations depending on the throughput of the target API endpoint, until a successful attempt is made.
Using strict rate-limiting for authentication and implementing lockout policies can be helpful in fixing broken authentication. Multi-factor authentication is another method for fixing the same.
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.
Quite often, APIs do not impose any restrictions on the size or number of resources that can be requested by the client/user. Not only can this impact the API server performance, leading to Denial of Service (DoS), but also leaves the door open to authentication flaws such as brute force.
Lack of resources and rate limiting is when an API allows as many numbers of requests from an API client and does not restrict the frequency of these requests. As a result, the server tries to fulfill these requests irrespective of the number.
When a client sends multiple requests at once, it impacts the server’s ability to process requests and makes the service slow for other users. A lack of rate limiting can impact the performance of an API server and allow attackers to launch a DoS attack.
Lack of rate limiting can also lead to brute forcing attacks. For example, if there’s no limit on how many attempts a user can make in order to login into a portal, attackers can exploit such a vulnerability and try to login with different passwords until a successful attempt is made. Since, there is no limit to the number of times the user can submit login requests, the attackers can take as long as required until they succeed.
In order to prevent resource and rate-limiting issues, the first step is to identify the normal usage for a specific functionality. For example, a maximum of 3 attempts should be allowed for a user to successfully make a login attempt, considering the possibility of he/she making a mistake while entering the credentials. Ideally, the rate limit for authentication endpoints should be much lower to prevent brute forcing attacks. Anyone trying to request resources at a higher rate should be blocked.
Limiting payload sizes will help to control any functionalities from the REST API request body and accessing these functions with a request payload that exceeds the maximum size causes the service to respond with error code.
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.
Binding client provided data (e.g., JSON) to data models, without proper properties filtering based on an allow list, usually leads to Mass Assignment. Either guessing objects properties, exploring other API endpoints, reading the documentation, or providing additional object properties in request payloads, allows attackers to modify object properties they are not supposed to.
When APIs expose resources, attackers can use these to generate their own requests or API calls to get access to such resources whose access rights are not with them. An attacker may adversely affect application functionality by manually tampering with a request to include additional parameters. The process of assigning values to multiple variables or object characteristics at the same time is known as "mass assignment."
An application object has multiple properties or characteristics that describe the object. For example, consider having a user object which contains properties such as user ID, name, address etc. If a user wishes to modify some of these properties, he/she should be able to do so, but at the same time, other parts of this user object should be restricted from the user. When an application automatically assigns user input to several program variables or objects, mass assignment vulnerabilities occur.
Mass Assignment is taken in to consideration during development of APIs, that is, in order to create more flexible APIs. But attackers take advantage of these kind of design decisions and try to exploit such vulnerabilities. They modify or create new program variables or object properties. Mass Assignment endpoint vulnerabilities are found through reconnaissance; therefore, attackers look for such frameworks that come with such type of vulnerabilities.
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.
Injection flaws, such as SQL, NoSQL, Command Injection, etc., occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s malicious data can trick the interpreter into executing unintended commands or accessing data without proper authorization.
HTTP request parameters, HTTP headers, and cookies are examples of untrusted user data. They can also originate from user-modifiable databases or stored files. The program's interpreter will confuse the user input as part of a command or query if the application does not correctly process the untrusted user data before putting it into a command or query. In this situation, attackers can provide data to a program that alters the meaning of the commands it issues.
Injection attacks occur when developers fail to sanitize user input properly. An API is just another way for untrusted user input to enter a program, injection vulnerabilities can also affect API systems. For example, in an SQL injection attack, the attacker injects data to manipulate SQL commands. In a command injection attack, the attacker injects data into the hosting server that manipulates the logic of OS system commands. Any application that mixes user information with programming commands or code is at risk.
Information leak, data loss, denial of service (DoS), and complete host takeover are all possible consequences of injection. Successful injection attacks frequently reveal enormous amounts of unauthorized sensitive data. Attackers may also be able to add new features, execute code remotely, or completely bypass login and authorization systems.
An API security solution must be able to recognize attackers exploring APIs with potentially dangerous data. Depending on how various backend application components and systems are built, injection vulnerabilities can be exploited in many areas of a request, including headers, cookies, URL query parameters, and message body variables. To properly detect injection problems early, the solution must evaluate all API traffic and build a baseline of usual API behavior. From the baseline, it will be easier to identify malicious data in an API request similar to that to an injection attack.
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.
Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to further attack systems, maintain persistence, pivot to more systems to tamper with, extract, or destroy data. Most breach studies demonstrate the time to detect a breach is over 200 days, typically detected by external parties rather than internal processes or monitoring.
When we talk about cyber-attacks, insufficient logging and monitoring is one of the major reasons for these attacks to take place. Malicious attackers always look forward to opportunities like lack of monitoring and a not so reliable detection and response mechanism.
Logging and monitoring systems are important as when a malicious attacker gains access to databases or other applications, a log is required to trace down the activities that took place during the course of the attack. It also helps in identifying attacks and preparing prevention mechanisms for the same. Log monitoring can also prevent downtime on sites and servers. Log management tools analyze logs and find issues and vulnerabilities within them, and help organizations to spend more time-solving problems and less time searching for them. It can save a lot of time and money.
Without well-structured logging methods, a company misses out on the audit trail for security analysis, giving attack vectors plenty of opportunity to penetrate various ecosystem components. Many organizations invest a fortune in securing their systems from external attacks and often mis out on the possibility of the internal attacks taking place. Such internal threats are a matter of concern for an organization as usually the suspicious activities inside organizations go unidentified. This is when attackers take advantage of the situation and pose severe threat to the organization as they have access to various resources. The solution to this is nothing but a proper logging and monitoring system in place.
Valency Networks is a very agile, friendly and fun loving atmosphere and yet we maintain a cutting edge technical vibrant work environment.