API4:2019 Lack Of Rate Limiting

Introduction

API4:2019 Lack Of Rate Limiting

Threat agents/attack vectors	Security weakness	Impacts
This vulnerability type is made possible because endpoints that serve data can be called upon many times per second by users/attackers. If the user/attacker requests some data so many times the system can no longer keep up and starts consuming all of it's resources this can even lead to a DoS (Denial Of Service) attack but the consequences might be even greater than that on certain authentication endpoints which might open the API up to forgotten password reset token brute forcing.	This security vulnerability is common in the wild and thus we may often encounter API's that contain no or weak rate limiting. Weak rate limiting can be defined in several ways but as long as the rate limiting is not sufficient for the purpose it server (like for example resource protection or protection against password attacks) it is not sufficient.	The impact can range from something like DoS up to enable authentication attacks, these are all in the higher end of the impact range because they have some serious potential to disrupt the normal workings of our API.

What is a lack of rate limiting?

Whenever an API is served a request it will have to respond, to generate this response the API requires resources (CPU, RAM, network and at times even disk space) but how much are required highly depends on the task at hand. The more logic processing happens or data is returned, the more resources are taken up by a single call and this can stack on quick. If we do not rate limit our API endpoints. This issue is made even worse by the fact that most API's reside on shared hosts which means they are all fighting for the same resources which could mean the attacker is disabling a secondary unrelated API by consuming all the resources.

Rate limiting issues in a dynamic resource environment

In today’s day and age, we rely heavily on setting up resources as we need them. We don’t want to pay for something we don’t use and thus we go looking for solutions different from the typical solution of adding servers. We might add in the option for dynamic scaling of resources and this is an interesting option but if you forget the addition of rate-limiting, you are sure to find yourself with a huge bill and empty pockets. A crafty attacker can easily start way more resources than required and of course, these resources are not free. Make sure you understand the risks that are connected to dynamically scaling servers or resources and the costs attached to them.

Example Attack Scenarios

There are simple examples of attacks related to lack of rate limiting on endpoint but those are easy enough, a somewhat deeper attack could be a user who discovers the endpoint to create a file which does have rate limiting and an endpoint to copy a file does not have rate limiting. At first this might seem hard to abuse but if we create a document on the system that has a large file size and then copy it over, we might trigger the server to run out of resources.

Example:

POST /createDocument.php

[
  {
    "Name": "677", 
    "Content": "AAAAA...AAAA"
		"fileSize":"21343243242343kb"
  }
]

With a response of the ID:

id=12

If we try to trigger this call multiple times we will notice rate limiting on the endpoint.

GET /cloneDocument.php?id=12

But there might be a GET call which is not rate limited and by triggering it multiple times we might consume all of the server's resources.

Let's add another example to make things more clear. We might be trying to recall the last 100 posts to a blog with the following URL

GET /api/v1/posts?limit=100

By executing this request with a parameter of limit=99999 we might trigger a lack of resources as well and this is also counted as lack of endpoint rate limiting.

Preventive measures against rate limiting issues

Using a docker container can be very handy as it has built in flags such as -m to determine exactly how much memory every container may consumer. This also allows for a much easier separation of different APIs.

We should make sure the client can only make a certain amount of request over a certain period. If we do this however we have to make sure that the client is notified when a rate limit is triggered or about to be triggered. This message should contain the amount of remaining requests before the limit is hit and/or the remaining time of the rate limit.

We need to verify on the client and server side that the request body and response are not too big. This is especially true for endpoints that return an amount of records specified by the client. The client can manipulate the amount of requests and cause a severe issue to occur if they request too many records at a time.

Every data type that the endpoint accepts should have an upper limit, for example integers should be limited to 5999. This ensure we never expose too great of a volume of data.

Conclusion

This again deceptive vulnerability is easy to overlook but can be a bit easier to automate as all we have to do is check all the API endpoints and see if they enforce a maximum size to the input or output, this requires a good understanding of what the APIs should accept or return. Better yet, good documentation helps identify issues easier which costs less in the long run.