Data, data, everywhere. How the lack of rate limiting contributes to severe security issues.
You’ve probably heard of the OWASP top ten or the top ten vulnerabilities that threaten web applications. OWASP also periodically selects a list of top ten vulnerabilities that threaten APIs, called the OWASP API top ten. The current API top ten are Broken Object Level Authorization, Broken User Authentication, Excessive Data Exposure, Lack of Resources & Rate Limiting, Broken Function Level Authorization, Mass Assignment, Security Misconfiguration, Injection, Improper Assets Management, and Insufficient Logging & Monitoring.
Many of these vulnerabilities affect application components besides APIs as well, but they tend to manifest themselves in APIs. Last time, we talked about a vulnerability that I consistently find in API-centric applications: OWASP API #3, Excessive Data Exposure. Today, let’s talk about something that will turn excessive data exposures into data breaches: OWASP API #4, Lack of Resources & Rate Limiting.
OWASP API #4
Lack of Resources & Rate Limiting is when the API does not restrict the number or frequency of requests from a particular API client. So an API client can make thousands or even more API calls per second, or request hundred or thousands of data records at once, and the server will still try to fulfill these requests.
This sounds pretty okay, right? In a lot of cases, the lack of resources and rate-limiting is not an issue. But sometimes, they could allow attackers to do something more.
When is this an issue?
First of all, a lack of rate-limiting can impact the performance of the API servers and allow attackers to launch DoS attacks. When a single client or multiple clients makes too many requests at once, requests from those clients can overwhelm the server’s ability to process requests, and in turn, make the service slow or unavailable for other users.
Another issue is that a lack of rate-limiting can lead to brute-forcing attacks on authentication endpoints and on endpoints with Broken Object Level Authorization. For instance, if there is no limit on how many times a user can submit login requests, malicious attackers can brute-force users’ passwords by trying to log in with different passwords until they succeed. On the other hand, if the application suffers from Broken Object Level Authorization, attackers can use a non-rate limiting endpoint to brute-force the IDs that point to sensitive data.
API Security 101: Broken Object Level Authorization
Finally, the lack of rate limiting can help attackers exfiltrate sensitive data faster if an API endpoint is leaking information. For example, let’s say that this endpoint is used to retrieve a user’s email and is not restricted by any form of access control. This endpoint will return 20 emails’ contents:
https://api.example.com/v1.1/emails/view?user_id=123&entries=20
This endpoint will return 5000, allowing attackers to read all of the users’ emails in one API call:
https://api.example.com/v1.1/emails/view?user_id=123&entries=5000
And when this API call returns a user’s email address and is not restricted by rate limiting:
https://api.example.com/v1.1/profile/email/view?user_id=123
Attackers can potentially fire up large numbers of API requests to harvest user email addresses:
https://api.example.com/v1.1/profile/email/view?user_id=123
https://api.example.com/v1.1/profile/email/view?user_id=124
https://api.example.com/v1.1/profile/email/view?user_id=125
...
...
...
https://api.example.com/v1.1/profile/email/view?user_id=2345
Preventing resource and rate-limiting issues
So how can you prevent these issues from happening? You need to restrict users’ access to resources! But that is easier said than done.
The appropriate rate and resource limit for each functionality often needs to be different. For instance, the rate limit for authentication endpoints should be much lower to prevent brute-forcing and password guessing attacks. The first thing you can do is to determine what is “normal usage” for that particular functionality. Then, block users whose request resources at a much higher rate than usual.
Determining the risk of rate limit issues is all about where the vulnerability is located in the application’s context. Next time, let’s look at another API issue that would also mean different things in different contexts: OWASP API #5, Broken Function Level Authorization, and how to determine its impact on the application. Next time, why you should audit sensitive functionalities in your APIs first.
What other security concepts do you want to learn about? I’d love to know. Feel free to connect on Twitter @vickieli7.
Want to learn more about application security? Take our free OWASP top ten courses here: https://www.shiftleft.io/learn/.
Top comments (0)