Unrestricted Resource Consumption: What It Is, How We Can Help

PUBLISHED ON December 11, 2023
LAST UPDATED Dec 11, 2023

No. 4 on the OWASP API Top 10 vulnerabilities list  is unrestricted resource consumption (after BOLA, Broken Authentication, and Broken Object Property Level Authorization). 

Lack of Resources and Rate Limiting on the 2019 OWASP API Top 10 list has become Unrestricted Resource Consumption in 2023. Although the name changed, these entries are basically the same – the new title is just focused on consequences, rather than the vulnerability. 

In addition, other limits, such as execution timeouts, maximum allowable memory, and the maximum number of processes, have also been included in addition to rate limiting.  

OWASP says of this vulnerability, “Exploitation requires simple API requests. Multiple concurrent requests can be performed from a single local computer or by using cloud computing resources. Most of the automated tools available are designed to cause DoS via high loads of traffic, impacting APIs’ service rate.” 

How Does an Unrestricted Resource Consumption Exploit Work?  

Imagine that bad guys could hack into your smart thermostat and adjust the thermostat. Big deal, you might think, until you got the electric bill that month.  

Imagine they could remotely open all the faucets in your house.  

Imagine that they could momentarily materialize in your kitchen, open the refrigerator door, then disappear, leaving that fridge door open.  

That’s kind of how #4 of the OWSP API Top 10 works.  

Well-constructed API endpoints, whether as part of their software or otherwise, should keep track of who’s making calls, and thereby consuming compute resources, database sessions, or even bandwidth between the endpoint and the Internet.  

But many APIs don’t keep tabs on this kind of stuff.  

OWASP gives this example:  

A service provider allows clients to download arbitrarily large files using its API. These files are stored in cloud object storage and they don’t change that often. The service provider relies on a cache service to have a better service rate and to keep bandwidth consumption low. The cache service only caches files up to 15GB. 

When one of the files gets updated, its size increases to 18GB. All service clients immediately start pulling the new version. Because there were no consumption cost alerts, nor a maximum cost allowance for the cloud service, the next monthly bill increases from US$13, on average, to US$8k. 

How ThreatX Can Help  

Designing protection in is always a great strategy, but realistically, enterprises don’t always even have source code for the APIs that run their business.   

ThreatX identifies and flags behavior indicative of an attempt to exploit unrestricted resource consumption – such as high error counts – from a single entity. ThreatX can then, in real time, implement rate limiting or block the user if there are other indications of malicious behavior. We can rate limit at the endpoint, host name, or entity level.  

How Our Approach Is Unique    

Real-Time Blocking     

Some API security solutions simply highlight potential API vulnerabilities, leaving security teams to investigate and recommend code changes. Other API solutions can identify attacks, but require security teams to try to model the complex behavior in a third-party WAF. Or worse, they create the necessity to block one IP at a time, often after the attack has successfully DDoSed a system. ThreatX doesn’t just tell you about your API vulnerabilities. Instead, we get at root causes of these kinds of vulnerabilities – malicious and suspicious traffic – and we block those API attacks in real-time.   

ThreatX recognizes attacker behavior indicative of an attempt to exploit endpoints with poor resource management or rate limiting; we then flag and watch that user. If the suspicious behavior continues, or is mingled with other sketchy behavior, then that user is blocked. The API endpoint is protected, even though it’s still vulnerable. This mitigation might be sufficient forever, or it might buy your dev teams time to remediate the vulnerability. Either way, your endpoint is still up and running.  

Step One of N…    

One caution on the OWASP Top 10 list of API vulnerabilities – it’s a great way to categorize vulnerabilities, but it’s not necessarily an attacker playbook. They don’t try one simple thing. They attack APIs by stringing together a series of attacks over time, often using federated and sophisticated botnets. Countering this approach requires the ability to correlate attack traffic across multiple IPs, the use of advanced bot protection, and the ability to detect identifiers and techniques to associate the traffic to a unique attacker.    

Identifying Risk     

In practice, attackers often camouflage their attempts to exploit this API vulnerability by flooding the endpoint with suspicious traffic, or simply by spraying the endpoint with benign requests.   

ThreatX cuts through this deceptive traffic, and blocks potential threats before they can bleed away resources and impact your SLA with your customers. ThreatX details API endpoint usage, visualizing both legitimate and malicious traffic. With this visibility, ThreatX customers can identify and rate limit attacking entities, preventing denial of service.   

Back to the original example … ThreatX comes along behind the bad guy and closes the refrigerator. We set that thermostat back to an energy efficient 62F. And we close the taps on the faucet before you get a $3,000 water bill.     

Learn more in The Definitive Guide to API Attack Protection. Or  request a demo  of the ThreatX solution.     

Tags

About the Author

Bret Settle

Bret has served in multiple executive roles for Corporate Express/Staples and BMC Software and has extensive knowledge of the software development and security products industries. Bret has been responsible for enterprise security in multiple roles and has been an innovator throughout his career and has a proven track record of building and developing high performing organizations and dynamic cyber security teams.