Researcher Tutorials

Rate Limits.. can we bypass them? by zseano

About the Creator

Me

zseano
 


About Hey! I'm zseano and I run BugBountyNotes. I do bugbounties full time and I managed to reach the top 10 on bugcrowd in just 8months from one program. I am lucky to attend live events by HackerOne and this is what inspired me to create this! :) I specialise in webapp testing and I love helping others. Feel free to reach out


I don't think rate limits need an explanation, but for those scratching their head: Rate limits are designed to stop you from abusing a certain action/endpoint, for example logging in (brute forcing an account). When a rate limit occurs the user is sometimes either blocked from performing that action for x time, or they are hit with captcha. In this tutorial we're going to go over some bypasses i've used in the past on bounty programs and places you can look.


First of all i'm going to outline common actions which should be protected by rate limiting, and places you can maybe score a bounty.

  • Login
    The most obvious. If there is no rate limiting on login then you can easily brute force accounts with ease.
  • Reset Password
    Not exactly a HUGE security flaw (so don't expect a bounty), but spamming a users' email with forgotten passwords links could get annoying. I've had bugs like this accepted before.
  • 2Factor Login
    Even if you know someones login credentials, if 2FA is enabled chances are you won't get any further. Yay. Sometimes the 2FA text/email/call you receive will be a 4-6 digit number and if no rate limiting applies here, what can we do? You guessed it, brute the code.
  • Enumerating users information
    So this one will require a bit of explaining as it isn't as simple as that, and I don't want people think you can spam programs with meaningless bugs. Let's imagine we've found an IDOR on this site and we can literally ping /api/?id=0-100000 and pull all their users data (incrementing 0 up to 100000). In my opinion, an API which returns a users private information should have rate limiting on it. (By private I mean things like email, phone number etc). Not only does this bug you just found have IDOR, but you can impress them more and advise them "Hey.. perhaps you should also rate limit this?". Rate limiting on sensitive actions can prevent attackers from making away with large amounts of data.
  • Sign up
    This all depends on the site and what actions a member can do. If for example it is a site which contains a voting system and you can manipulate this mass signing up & voting, signup should require rate limiting. A lot of programs say "spam" is out of scope, but this is where you begin chaining bugs:

    - Find rate limit bypass on signup.
    - Find rate limit bypass on sending messages to other users.
    - Find bypass for link bans in messages.

    Notice how we chained a ton of bugs to essentially cause a huge problem? If rate limiting existed on signup the impact would of been less.

Methods to bypass

Here are some methods I have used with success to bypass rate limits:
  • %00, %0d%0a, %09, %0C, %20, %0
    Notice the screenshot at the top? I first reported that %00 bypassed a certain endpoint, and when they replied saying it had been fixed, I simply tried %0d and the rate limit was again bypassed. As pointed out in my tweet, using things like null byte and CRLF can sometimes be perceived as spaces, therfore leading to a potential rate limit bypass. An example is when logging in: let's imagine a site has rate limit on logging in, but the rate limit applies to the account. So if we try to login to [email protected] 25 times, you may become locked out for x time. But you're not locked from trying [email protected] A good bypass is to use [email protected]%00%00 and see if that bypasses. Make sure when testing this bug you verify that logging into your OWN account with %00 on the end actually works first (depending how they handle the character).
  • Changing cookies
    I've seen some interesting cases in which a site will rate limit you based on your session. For this method I will sometimes change the session cookie to be anything and see if it accepts it, or i'll work out a way to re-generate a new session with ease.
  • Changing IP
    Of course the most common. An amazing read is over here by @arneswinnen on HackerOne: https://hackerone.com/reports/127844. He explains everything perfectly.
  • Mobile sites/apps
    In my experience most mobile apps and sites are vulnerable to rate limiting bypass purely because they simply don't have any protection in place. I'm not sure why devs forget rate limiting their mobile endpoints.. but if you're a mobile dev tweet me and let me know ;)

Final words

As explained a few times in this post, think before reporting. Rate limiting doesn't have to exist on EVERY action/endpoint, so make sure the rate limiting bypass you've found has an actual security impact. If you can brute force accounts, manipulate important data, harvest private data, or chain a few bugs to unleash mass spam across a site, then get it reported. (I've probably missed some common actions, so please use your head.

Happy hunting!