📦

API4:2019 Lack of rate limiting

introduction

API4:2019 Excessive Data Exposure

Threat agents/attack vectorsSecurity weaknessImpacts
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/attack requests so 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.
Untitled
Untitled

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.

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 Excessive Data Exposure

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 enfore a maximum size to the input or ouput, this requires a good understanding of what the APIs should accept or return. Better yet, good documenation helps idenitfy issues easier which costs less in the long run.