Mitigating OWASP API Security Risk: Lack of Resources and Rate Limiting using F5 XC Platform
Introduction:
The Introductory article covered brief presentation of OWASP Top 10 Web Application and API Protection (WAAP). This article is continuation of the series and shows mitigating API Vulnerability Lack of Resources and Rate Limiting using F5 Distributed Cloud (F5 XC) WAAP.
Introduction to Lack of Resources and Rate Limiting:
API responds with users API request, to generate this response the API requires resources like CPU, memory, RAM etc. These resources consumption is dependent upon logical processing or data returned. Without rate limiting the requests single user or a group of users can make too many requests at once and this causes overwhelming the server’s ability to handle API requests causing system to be vulnerable. These continuous requests can bring an API to unresponsive, slow down the service and in some instances this leads to Denial of Service (DoS).
This vulnerability plays a key role, and it should be considered. Hence this is ranked #4 in 2019 as API security risk Lack of Resources and Rate Limiting.
Attack Scenario:
In this demo we are going to generate huge traffic and observe the server’s behaviour along with its response time.
Above results shows higher response time when abnormal traffic is sent to single API endpoint when compared to normal usage. By further increase in volume server can become unresponsive, deny requests from real users and results in DoS attack.
Customer Solution:
F5 XC WAAP helps in solving above vulnerability in the application by rate limiting the API requests there by preventing complete consumption of memory, file system storage, CPU resources etc. This protects against traffic surge and DoS attacks.
This article aims to provide F5 XC WAAP configurations to control the rate of requests send to origin server.
Step by Step to configure Rate Limiting in F5 XC:
These are the steps to enable Rate Limiting feature for APIs and its validation
- Add API Endpoints with Rate Limiter values
- Validation of request rate to violate threshold limit
- Verifying blocked request in F5 XC console
Step 1: Add API Endpoints with Rate Limiter values
- Login to F5 XC console and Navigate to Home > Load Balancers > Manage > Load Balancers
- Select the load balancer to which API Rate Limiting should be applied.
- Click on the menu in Actions column of app Load Balancer and click on Manage Configurations as shown below to display load balancer configs.
- Once Load Balancer configurations are displayed click on Edit configuration button on the top right of the page.
- Navigate to Security Configuration and select “API Rate Limit” in dropdown of Rate Limiting and click on “Add Item” under API Endpoint section.
- Rate limit is configured to GET request of API Endpoint “/product/OLJCESPC7Z”.
- Click on Apply button displayed on right bottom of the screen.
- Click on “Save and Exit” for above configuration to get saved to Load Balancer.
2. Validation of request rate to violate threshold limit
Request is sent for the first time after configuring API Endpoint and can be able to see the response along with status code 200.
Upon requesting to the same API Endpoint beyond threshold limit blocks the request as shown below,
3. Verifying blocked request from F5 XC console
- From the F5 XC Console homepage, Navigate to WAAP > Apps & APIs > Security and select the Load Balancer.
- Click on Requests to view the request logs as below,
- Can be able to see requests beyond the rate limiter value get dropped and response code is 429.
Conclusion:
When application receives an abnormal amount of traffic and this may lead to outage, F5 XC WAAP protects APIs from being overwhelmed by rate limiting the requests. This in turn saves the resources from the complete consumption of quota or resource limit. Rate limiting helps in preventing DoS attacks and ensures service availability. With one solution called F5 XC helps customers to less concern about addressing these vulnerabilities by rate limiting for multiple domains/server URLs as well as its endpoints by performing very few configurations in F5 XC console rather than doing independently which in turn saves lot of labour effort.
Related Links:
- chaithanya_dileepEmployee
Nikoolayy1 Jmeter is used here only as a tool to generate traffic so that F5 XC can validate rate limiting feature and supports it. When Shape's Bot defense is enabled it automatically detects and captures the bot traffic.
Nice article but shouldn't the F5 Shape security in most cases detect the bad bot traffic from Jmeter even if the source ip addresses and User-Agent headers are changed (Jmeter supports changing User-Agent headers and most modern bots rotate the source ip addresses and user-agent headers) and block it? Maybe the Rate Limit is as a second option if the Bot is really new and advanced till Shape Security blocks it?