API-04 Unrestricted Resource Consumption

If you’re familiar with the previous API Top 10 this is another returning issue. Even though APIs can run with fewer resources due to their lack of a front end, use various micro frameworks and may encounter less traffic it is important to consider the risk of an application level DoS attack caused by unrestricted resource consumption. These resources can be things like RAM or storage space, however APIs will often use integrations with third parties such as SMS. 3rd party integrations will usually have pricing based on use, if you use the service more you will have to pay more. An attacker may be able to consume these resources costing you a lot in additional fees!

Unrestricted resource consumption is simply a vulnerability that causes denial of service to the API or its required 3rd party integrations. This is particularly of concern when deploying APIs with reduced virtual or real hardware specifications. 

We rejoin Suzy from Suzy’s Social, the new microblogging platform, as she adds text based 2 factor authentication. Users will be able opt in to the new service which will send them a code when they login via an SMS to a verified user. Viv has had her account taken a lot so this is a relief! While paying for the text service will get expensive if the website explodes in popularity and may not be the most secure 2 factor authentication, accessibility won out, everyone has a phone after all! After a few months, and a few complaints about not getting 2 factor authentication codes Suzy logs in to check her usage of the text message service, only to be faced with a bill from $1,000 to $10,000. She was expecting usage to increase when going live, but that’s a lot higher than she predicted when doing the calculations before launch. The messaging service cuts her off at $10,000 as it’s the limit for her current plan, probably why people weren’t receiving codes – she hit the limit before the end of the month. Before she reluctantly goes to increase her plan she double checks the logs to understand the usage. As she checks the logs she notices that a single number has received the vast majority of text messages, several thousand dollars! Our attacker Adam strikes again. Frustrated and angry after the fixes stopped his account selling business, he decides to be disruptive this time and stop 2FA codes from being sent to accounts and increase the costs to run Suzy’s Social!

These kinds of vulnerabilities can be very disruptive, as they can be knowingly abused but also accidentally abused! With APIs being deployed on smaller virtual servers to save costs due to lower traffic or integrating with third parties to save development time before launch. It is important to prepare for sudden popularity or both unintentional and intentional abuse.

To resolve this vulnerability where possible place limits on resources or configure resources to scale with demand (to a point) depending on business needs. Some of these introduced limits will naturally resolve this vulnerability, for example placing a file size limit on a file upload, however others will not so it is important to understand how these resources are used.  If consumption does increase ensure logs are reviewed to highlight any suspicious traffic. For third party API calls, introduce rate limiting or batching to reduce the total number of API calls, add a spending limit to avoid unexpected bills and take advantage of any security the third party provides.

Harold Bell

Harold Bell is the Director of Content Marketing at Noname Security. He has over a decade of experience in the IT industry with leading organizations such as Cisco, Nutanix, and Rubrik, and has been featured as an executive ghostwriter in Forbes Technology Council and Hacker News.

All Harold Bell posts All of Harold Bell's posts