OWASP API #4: Lack of Resources & Rate Limiting
This section
As a reminder, we started with this section three weeks ago. Our main purpose is to share the top cybersecurity attacks that applications are suffering nowadays and help by explaining how you can prevent them from happening.
In each story, we go through ‘Brief explanation’, ‘Is my API vulnerable?’, ‘Attack scenarios’ and ‘How to prevent?’, so by the end you have a comprehensive understanding.
If you missed the previous articles, we encourage you to go have a look. We have already covered:
API #4: Lack of Resources & Rate Limiting
Although it is not the first time we mention this topic, this week we are going to put special focus into it. The good thing, is that complying with it is definitely achievable, you just have to get use to it and build momentum together with a methodology that helps your organization set up the proper controls in the needed scenarios.
When you are lacking resources and rate limiting, your application can increase the probability of being a target for a wide range of attacks. The spectrum goes from using your application for credential stuffing, exploiting log in and reset password endpoints to successfully execute an account takeover, or a simple DOS (Denial of Service) due to not having enough resources to satisfy the demand.
Every application has limited resources and computer power available. More often than not, the above contemplates common flows and traffic only, so we ask you to go beyond that.
The advantage of properly setting up this controls, is that you are going to have a much more secure application plus you will also discourage most attackers to target you and they will go hunt an easier pray.
Enough intro, lets get right into it 💪🏻
Brief explanation
Lack of Resources & Rate Limiting occurs when the application does not properly set limits for the resources that can be requested or triggered.
Is my API vulnerable?
Your API is indeed vulnerable when you are missing the following limits:
- Execution timeouts.
- Max allocable memory.
- Number of file descriptors.
- Number of processes.
- Request payload size (e.g. uploads).
- Number of requests per client/resource.
- Number of records per page to return in a single request’s response.
Example attack scenario #1
An attacker uploads a large image by issuing a POST request to /api/v1/profilepicture. When the upload is complete, the API creates an avatar for the user.
The attacker attempted to upload an image with a size of 512mb. Due to the size of the uploaded image, available memory of the instance running the application is exhausted during the creation of thumbnails and the API becomes unresponsive.
Example attack scenario #2
We have an application that contains the users list on a UI with a limit of 200 users per page. The users list is retrieved from the server using the following query:
/api/users?page=1&size=100.
An attacker changes the size parameter to 200 000, causing performance issues on the database. Meanwhile, the API becomes unresponsive and is unable to handle further requests from this or any other clients (aka DOS).
Be aware that if certain conditions are met, the same scenario might be used to exploit an Integer or Buffer Overflow.
How to prevent?
- For sensitive operations such as login or password reset, implement rate limits by API method (e.g., authentication), client (e.g., IP address), property (e.g. username).
- Notify the client when the limit is exceeded by providing the limit number and the time at which the limit will be reset.
Some examples include:
- For login endpoints, allowing only 5 requests attempts per minute, filtering by username and IP address.
- When retrieving lists, set default offset and limit sizes, but also max and mins.
Conclusion
In a few minutes, we have gone through what lack of resources imply while also giving some examples to establish measures. As mentioned above, the amount of effort to establish proper controls is minimal when compared to the advantages it can give you, as it will improve your applications daily performance, give you a better understanding of your platform and best of all: deter attackers from targeting your services.
Although we did not mention it, the different controls can be at a database, backend code (better) or web application firewall level. What matters is that you get used to configuring them as soon as possible in your workflow.
By setting proper controls, Lack of Resources & Rate Limiting will be easily mitigated, and what’s better, it will place you way ahead of your competitors which are probably missing them 😉
Thank you for reading this week’s story from our OWASP API TOP 10 series. If you have any doubts, do not hesitate to contact anyone at Strike or reach out to me through LinkedIn, we will be more than happy to help you!
Finally, if you want to see daily news, tips and funny related memes, be sure to give us a follow there too.
Cheers from Strike 🙂
