**Note: The content in this article is only for educational purposes and understanding of cybersecurity concepts. It should enable people and organizations to have a better grip on threats and know how to protect themselves against them. Please use this information responsibly.**
Not having good resource control and request limits is a significant vulnerability in web apps and systems. When a system doesn’t limit how many requests a user can make in a set time, it leaves itself open to different kinds of attacks. One of the most common dangers is brute-force attacks. In these, attackers send loads of requests over and over again to try and guess login details, like passwords or API keys. If there’s no system to slow down requests, attackers can try tons of combos in fast succession. This gives them a much better shot at breaking into the system.
Besides brute-force attacks, not having request limits can cause significant performance problems and even cause system crashes. When attackers send too many requests, they use up server resources like CPU, memory, and bandwidth. This slows everything down or can lead to a complete denial-of-service (DoS). During a DoS attack, genuine users can’t get to the system because bad traffic is hogging all the resources. This doesn’t just make the system hard to use – it also breaks user trust. In the end, this can cost the organization financial and reputational damage.
Moreover, failure to impose request limits can also lead to abuse of system functionality. For example, attackers could use automated tools to send continuous requests to a specific endpoint, triggering unintended consequences like data extraction, spamming, or manipulating system behavior in ways the developers never intended. Without proper throttling mechanisms, the system is left vulnerable to these kinds of exploitation.
Before the walkthrough install VAmPI and Postman if you have not installed them by clicking on the link below:
- Understanding and Installing VAmPI – A Vulnerable REST API (Part 1)
- Installing Postman: An API testing tool
Walkthrough
In this walkthrough, we will perform a brute-force attack using Burp Suite’s Intruder module to test the login functionality of a web application. By capturing a login request and configuring the Intruder with two sets of payloads, we will attempt to pair multiple usernames and passwords to identify valid credentials, analyzing the response lengths to distinguish between successful and failed login attempts.
- Proxy the Login Endpoint:
Configure Burp Suite to proxy the login endpoint of the application.
Make sure your web browser or API tool (like Postman) is set up to use Burp Suite as a proxy. You can set 127.0.0.1 as the proxy and 8080 as the port.
For Postman users, head to Settings > Proxy and input 127.0.0.1 for the HTTP Proxy and 8080 for the Port.
Send a login request to Burp Suite and capture it.
Right-click the captured request and send it to Intruder for further manipulation.
- Configure Intruder
In the Intruder tab, place two payload positions over the values of the username and password parameters by clicking the Add $ button.
Also, choose the Pitchfork attack type. This allows you to pair each username with a corresponding password.
- Switch to the Payloads tab.
For the first payload set, load a long list of usernames. Ensure the list ends with the names of the two valid users.
For the second payload set, load a matching list of random passwords, ending with the correct passwords for the two valid users.
- Start the attack by clicking the “Start Attack” button.
Observe the results in the Intruder tab.
Notice that all requests return a 200 OK response code.
Distinguish between failed and successful requests based on the length of the response. Typically, failed responses will have a consistent length, while successful ones will differ.
Successful ones have a length of 391 bytes.
- Identify the Vulnerability
Response Length Analysis: Compare the lengths of the responses to identify valid login attempts. Even though the application returns 200 OK for all requests, the difference in response lengths helps to distinguish between failed and successful logins.
Lack of Rate Limiting: You’ll see that the system doesn’t stop or limit multiple login tries. This lack of limits shows that the system is open to brute-force attacks. Bad actors can try loads of username and password combos without getting blocked.
Conclusion
By following these steps, we have successfully demonstrated a lack of resources and rate limiting vulnerability in the application. This weakness allows hackers to try loads of usernames and passwords, which could let them break in without permission. It shows why it’s essential to put in place robust rate limiting on how often someone can try to log in and manage computer resources to safeguard against these kinds of attacks.
