Bypassing Cloudflare WAF with Host header manipulation

Hey Folks! Thanks for your responses on my last blog. Let’s learn something new today as it is going to be damn interesting one.

If you have been into web application Pentesting you must have encountered or got stopped by Cloudflare for sure. Cloudflare secures and ensures the reliability of your external-facing resources such as websites, APIs, and applications. It protects your internal resources from bots, malicious attacks, DDos and handles the traffic as per the rules.

I was testing one of the web application (say Example.com) and there was a login page. I wanted to check if the application is vulnerable to bruteforcing or not.

I entered the credentials and intercepted the request in Burp proxy. Forwarded the request to intruder and wanted check if there is any Rate-Limit has been implemented to stop me from bruteforcing the password.

Unfortunately, after some attempts I got stopped by Cloudflare with the usual error message saying that my IP address has been banned by the application owner and no more requests login attempts can be done (Basically Rate-limiting was implemented with Cloudflare).

I got curious as this seems to be a good challenge. If you carefully observe the application URL in the Host header part of the request, you will see that it starts from prod.*(Sorry I have to blur the later part, assume the address is prod.example.com). I opened the browser and intentionally typed mrod.example.com and I got redirected to prod.example.com.

I opened the Burp again and checked the response in Repeater tab with the same changes in Host header. Guess what! I bypassed the cloudflare restriction as the response was throwing the different error related to wrong password now.

At this point of time I knew that what I have to do in-order to perform the bruteforcing without getting caught by Cloudflare. I made changes in the position for the payload, this time I will be changing the value “prod” in the host header part with different words and simultaneously changing password field.

As expected, request didn’t get caught by Cloudflare and was able to perform bruteforce without any trouble (No 429 Status codes in response)