Rate Limit Bypass
Last updated
Last updated
Use Trickest to easily build and automate workflows powered by the world's most advanced community tools. Get Access Today:
Attempts should be made to perform brute force attacks on variations of the targeted endpoint, such as /api/v3/sign-up, including alternatives like /Sing-up, /SignUp, /singup, /api/v1/sign-up, /api/sign-up etc.
Inserting blank bytes like %00, %0d%0a, %0d, %0a, %09, %0C, %20 into code or parameters can be a useful strategy. For example, adjusting a parameter to code=1234%0a allows for extending attempts through variations in input, like adding newline characters to an email address to get around attempt limitations.
Modifying headers to alter the perceived IP origin can help evade IP-based rate limiting. Headers such as X-Originating-IP, X-Forwarded-For, X-Remote-IP, X-Remote-Addr, X-Client-IP, X-Host, X-Forwared-Host, including using multiple instances of X-Forwarded-For, can be adjusted to simulate requests from different IPs.
Altering other request headers such as the user-agent and cookies is recommended, as these can also be used to identify and track request patterns. Changing these headers can prevent recognition and tracking of the requester's activities.
Some API gateways are configured to apply rate limiting based on the combination of endpoint and parameters. By varying the parameter values or adding non-significant parameters to the request, it's possible to circumvent the gateway's rate-limiting logic, making each request appear unique. For exmple /resetpwd?someparam=1.
Logging into an account before each attempt, or every set of attempts, might reset the rate limit counter. This is especially useful when testing login functionalities. Utilizing a Pitchfork attack in tools like Burp Suite, to rotate credentials every few attempts and ensuring follow redirects are marked, can effectively restart rate limit counters.
Deploying a network of proxies to distribute the requests across multiple IP addresses can effectively bypass IP-based rate limits. By routing traffic through various proxies, each request appears to originate from a different source, diluting the rate limit's effectiveness.
If the target system applies rate limits on a per-account or per-session basis, distributing the attack or test across multiple accounts or sessions can help in avoiding detection. This approach requires managing multiple identities or session tokens, but can effectively distribute the load to stay within allowable limits.
Note that even if a rate limit is in place you should try to see if the response is different when the valid OTP is sent. In this post, the bug hunter discovered that even if a rate limit is triggered after 20 unsuccessful attempts by responding with 401, if the valid one was sent a 200 response was received.
Use Trickest to easily build and automate workflows powered by the world's most advanced community tools. Get Access Today:
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
