API4:2019 – Lack of Resources & Rate Limiting: The What, Sample Exploit, and Prevention Methods

Lack of resources & rate limiting is #4 on the OWASP Top 10 API Security Risks 2019. It is a prevalent API security risk. As per OWASP, rate limiting and resource-related flaws in APIs are quite easy to exploit, especially with automated toolkits and for-hire services. But the exploitation of the lack of resources & rate limiting flaws has severe consequences for the organization.

So, what exactly is this security risk, and how do you prevent it? Keep reading to find out as we delve deep into API4:2019 of the OWASP Top 10 API Security risk 2019.  

What is OWASP API4:2019 – Lack of Resources & Rate Limiting? 

The API Context: Resources & Rate Limits 

Before delving into the lack of resources and rate limiting, let us set the context for you. 

APIs enable apps, computers, components, and microservices to connect and communicate with one another. It enables users/ clients to access functionalities and resources while using an app/ program. They are invisible but form the backbone of modern-day, headless IT architecture. 

For example, when you shop using an e-commerce app, different APIs are executed to 

• fetch product details for your search queries 
• get you personalized pricing and offers
• collect your login details to start your purchase
• view the shopping cart and check out
• make payment

You don’t individually or directly interact with any APIs used for search, payment, pricing, login, and other functions. The e-commerce app offers you the interface with which you interact. When you enter a search query on the app, the app connects to the server and the appropriate API gets executed. The API interprets your query, connects to the backend database, and returns results to your phone/ device, all within a few seconds or milliseconds.

In fulfilling the user request, the API uses a certain amount of your resources, such as CPU, computing power, RAM, server bandwidth, storage, and so on, to run the code and generate a response. How much of these resources get used? This purely depends on the task at hand for the API and the business logic of the endpoint. For requests that require a lot of data to be returned or logic to be processed, more resources get used up in a single call. 

Note that apps and APIs have limited resources and computing power. If too many requests or even a few large requests are made to the API, the resources erode quickly. Therefore, OWASP recommends organizations place rate limits on APIs. These rate limits are defined in diverse ways: 

• limiting the number of API calls per hour or day
• limiting the frequency of API calls 
• limiting the number of API calls per unique user
• limiting the amount of data that can be returned per call

By placing API rate limits, you can ensure that third-party users and malicious actors don’t diminish server resources and API performance.

How does API4:2019 – Lack of Resources & Rate Limiting Arise?

Too often, developers/organizations don’t impose restrictions on the size and number of resources requested by the user/ client in an API call or on the number of API calls a client/user can make within a given time frame.

When the app/ API does not have properly defined limits for API calls and resources that can be triggered, a lack of resources & rate limiting flaw occurs.

How Do Attackers Exploit the Lack of Resources & Rate Limiting Vulnerability? 

To exploit these flaws and overwhelm the API, attackers don’t need complex code or anything elaborate; simple API requests will do the trick. Attackers simply submit many (seemingly) legitimate API requests or a few large ones that require lots of processing power (such as zip bombs or archive files that need lots of processing power to open).

This exhausts the API resources like CPU, system memory, storage, network bandwidth, etc. API-side hardware may also experience exceptions and buffer overflows.

When the resources are exhausted, the API and application performance goes down, causing crashes and downtimes and making these resources unavailable to legitimate users. Or it slows down the processing of genuine inbound API requests from genuine users.

Attackers don’t have to authenticate themselves to carry out these attacks. They can leverage these flaws to carry out various API abuses and attacks. For instance,

• Brute forcing passwords becomes easier without API rate limiting for login functionalities.
• DoS and DDoS attacks are much easier to orchestrate as attackers send voluminous requests to exhaust the API. 
• Attackers use the absence or improperly defined rate limits to conduct credential and token cracking attacks. Using these stolen credentials, they could steal data for themselves or sell the stolen credentials on the dark web. 
• Attackers also leverage these flaws to orchestrate application logic abuse by using various attack mechanisms like 
  • stealing access tokens
  • content-based attacks
  • Unauthorized use of admin functions

Exploiting a lack of resources & rate limiting is scalable and parallelizable. In other words, attackers could send multiple concurrent requests from a single local computer or several machines concurrently. They could also leverage cloud computing resources and automated tools to send multiple concurrent requests to the API.

Being commonly hosted on shared machines, attackers can leverage one vulnerable API endpoint to overwhelm others and exhaust the resources of the entire framework.

While most instances of lack of resources & rate limiting are nefarious, there are less nefarious instances too. APIs are used by multiple businesses in B2B situations. One of the businesses using the API may make excessive requests. Though not malicious in their intent, they do inadvertently slow down responses to API calls of other businesses.

What Causes Lack of Resources & Rate Limiting? 

Lack of resources & rate limiting flaws occurs when one or more of the following limits for APIs are missing or set inappropriately. 

• Execution timeouts
• Maximum allocable memory
• Number of file descriptors
• Number of processes
• Request payload size, especially at the networking layer
• Number of requests per client/resource
• Number of concurrent requests by a single user/ machine
• Number of records per page to return in a single request-response

The main cause of API4:2019 flaws is configuration mistakes by developers. These configurations could occur at the API gateway, inline networking gear, CDN, load balancer, or the API itself.

Even when developers and IT teams don’t perform load testing and performance testing regularly, you may end up missing rate limits or inappropriate rate limits (that are too high or too low).

Example 1: 

In our online shopping example, the attacker discovers that the profile page lets users include their avatars to personalize their customer experience. To this end, users can also upload their avatar image but do not specify the maximum size of the image file. So, the attacker sends a massive image file in the API call.

This triggers the API to resize the image file to the proper dimensions, using up large amounts of API resources. The API responses become slower for other users, and the API may become unavailable. So, the attacker simply used a large file upload to orchestrate this application-level DoS attack, taking the API offline.

The SoundCloud Rate Limiting Exploit

In 2020, a research team found that the SoundCloud API had a lack of resources & rate limiting flaws. No validation was performed for the number of tracks requested in a single request.

Attackers could leverage this flaw to request an arbitrary number of tracks in just one request, overwhelm the server and make SoundCloud unavailable to genuine users. SoundCloud eventually fixed this flaw.

How to Prevent Lack of Resources & Rate Limiting? 

Properly Define and Strictly Enforce Rate Limiting Policies 

This is a no-brainer. Every organization must clearly define and strictly enforce comprehensive rate-limiting policies. You can use OWASP rate-limiting prescriptions and best practices to set these limits. But you must analyze and tailor the limits for your unique context. You must match your rate-limiting policies to your API methods, properties, resources, clients, addresses, etc.

Define rate limits for

• API calls for specific timeframes like a minute, an hour, a day, etc.
• the frequency of API calls in a given timeframe
• number of API calls per unique user and IP address
• The payload size or the amount of data that can be returned per call. Enforce an upper limit on the data size, including the maximum length of strings and elements in the array for all incoming parameters and payloads. 
• retrieving lists with default offset and limit sizes 
• container resources 
• all login endpoints 
• each sensitive operation, such as login, payment, password reset, etc. 
• each API method (for instance, authentication, access control, etc.)
• each property, like username, email id, etc. 
• each geography – you can automatically block users from geographies where your business isn’t operational. 

Whenever the client exceeds the upper limit, they should be notified of the limit number and when the limit will reset. You should also use execution timeouts since requests exceeding certain time limits are often candidates for resource depletion. By implementing execution timeouts, you can prevent high resource usage by shared business users or threat actors.

You must also consider enforcing rate limits on the load balancer, WAF, API gateway, reverse proxy, and other infrastructure that handles inbound API requests. You should also regularly check the compression ratios.

Use Response Caching

Response caching enables you to reduce the load on the API server drastically. All responses are sent from the caching server rather than the origin server. Most modern API gateways provide some form of response caching.

Implement Server-Side Validation

All incoming requests need to be validated on the server side to ensure the request body parameters, query strings, response, etc., are not too large or too short.

Implement Robust Access Controls, Authentication & Authorization Policies 

Attackers often leverage the lack of proper access controls and authentication and authorization flaws to orchestrate rate-limiting attacks. By implementing strict, role-based access controls, you can ensure that only authorized users have access to resources, especially sensitive data, and only within the permitted limits.

By enforcing strong authentication and authorization policies, you can ensure that only legitimate users submit requests for accessing or modifying sensitive content like login credentials, pricing, etc.

Identify Flaws Proactively from the SDLC Stages

Since a lack of resources & rate limiting are caused by configuration errors and implementation flaws, you must proactively find and fix these flaws as early as possible.

Automated API testing frameworks such as Postman or SoapUI can be used to test the API endpoints for API4:2019 – lack of resources & rate limiting vulnerability. These tools can test for rate limiting and throttling and verify that the API responds appropriately to invalid requests.

API Vulnerability Scanning 

Not every team has the time or the resources to fix vulnerabilities proactively in the SDLC. This is where API vulnerability scanning tools such as the Infinite API Scanner come into the picture. This scanner embeds manual pen testing into the vulnerability scanner to perform both Blackbox and Graybox testing (with credentials) to give a complete list of vulnerabilities.

Monitor all Traffic and Incoming API Requests with a WAAP Solution

Modern cloud WAAP solutions such as AppTrana act as shields and monitor all your incoming traffic and API requests in real-time to detect suspicious behaviour. Specifically on rate limiting, look for an AI-driven solution like AppTrana that does a behavioural analysis of past traffic and automatically applies rate limits on various parameters, including IP, Geolocation, URI, and session/host.

Conclusion

Lack of resources & rate limiting is a widespread API security risk that cannot be prevented using traditional security tools. Incorporating secure coding practices, performing periodic DAST scans and pentesting, and leveraging an API security solutions effectively prevent these and other API security risks.

Stay tuned for more relevant and interesting security updates. Follow Indusface on Facebook, Twitter, and LinkedIn