API requests consume resources such as network, CPU, memory, and storage. The amount of resources required to satisfy a request greatly depends on the input from the user and the business logic of the endpoint. APIs do not always impose restrictions on the size or number of resources that can be requested by the client or user. Not only can this impact the API server performance, leading to Denial of Service (DoS), but it also leaves the door open to brute-forcing and enumeration attacks against APIs that provide authentication and data fetching functionality. This includes automated threats like credential cracking and token cracking among others.
When determining impact, it is best to break down the impact of this issue into two sub-components:
In the example above of a lack of resource limit, the attacker has increased the max_return and page_size values for the search filter from 250 to 20,000. This increase would cause the application to return an excessive number of items in response to a query. It could also cause the application to slow down or become unresponsive for all users.
In 2020 the Checkmarx research team found that SoundCloud had not properly implemented rate limiting for the /tracks endpoint of the api-v2.soundcloud.com API. Since no validation was performed for the number of track IDs in the ids list, an attacker could manipulate the list to retrieve an arbitrary number of tracks in a single request and overwhelm the server. Under normal conditions the request issued by the SoundCloud WebApp includes 16 track IDs in the ids query string parameter. The researcher was able to manipulate the list to retrieve up to 689 tracks in a single request causing the service response time to increase by almost 9x. According to Checkmarx “This vulnerability could be used to execute a Distributed Denial of Service (DDoS) attack by using a specially crafted list of track IDs to maximize the response size, and issuing requests from several sources at the same time to deplete resources in the application layer will make the target’s system services unavailable.”
Traditional security controls like WAFs, API gateways, and other proxying mechanisms will commonly offer basic or static rate limiting which are difficult to enforce at scale. Security teams may not know enough about the application design to know what “normal” looks like in order to enforce limits to thwart attackers while not impacting business functionality. WAFs and API gateways lack the context required to inform security teams on what a normal value should be for an API parameter, and they will miss attacks where an attacker manipulates a single API parameter value to overwhelm the application. These proxies may also only cover ingress, or inbound requests, as opposed to egress traffic, or outbound requests and responses.
An API security solution must be able to identify calls to API endpoints and alterations to API parameter values that fall outside of normal usage. This would be done by analyzing all API traffic in order to create a baseline of typical behavior and identifying deviations that fall outside of that baseline.
In the example above an API security solution will have created a baseline of values for the max_return and page_size parameters and will identify that a value of 20,000 is abnormal. The solution could then alert on and block an attacker who crafts API requests that deviate from the baseline.
Like many other API breaches, the Optus security incident highlights the importance of dedicated API security.
Salt Security's Roey Eliyahu and TAG Cyber's Ed Amoroso sat down together for a joint webinar on API security and zero trust. Check out the takeaways.