Welcome back, aspiring cyberwarriors and bug bounty hunters!

Hacking web applications nowadays requires not just a well-written exploit but also a way to bypass a Web Application Firewall (WAF). Despite being a staple of modern security architecture, WAFs are often misunderstood: they are usually treated as magic shields when, in fact, they are complex systems with strengths, limitations, and blind spots.

In this article, we will cover three core topics: WAF operation, WAF fingerprinting methods, and bypass techniques. Let’s get rolling!

Understanding Web Application Firewalls and Detection Logic

A Web Application Firewall (WAF) is a security tool that sits in front of your web app and checks every incoming request before it reaches your code. It operates at Layer 7 of the OSI model, the application layer where HTTP traffic lives. Unlike traditional network firewalls, a WAF looks at the actual content of requests, like headers and URLs, not just their source.

WAFs typically use three methods to assess requests.

First is signature-based detection, similar to antivirus software. The WAF compares incoming requests against a list of known attack patterns and blocks any matches. This method is fast and effective for common attacks, but it can miss variations.

Next, anomaly scoring assigns points for various suspicious elements within a request. When the total score exceeds a threshold, the WAF blocks the request. This method is flexible because a single odd detail isn’t concerning, but a combination is.

Finally, behavioral detection focuses on client activity over time. The WAF monitors request rates and patterns and shuts down suspicious behavior like automated login attempts, even if each request seems harmless.

Combining these strategies gives a WAF a strong understanding of traffic, making it a key defense for serious web applications.

Fingerprinting a WAF

Before you do anything with the target, it’s smart to see whether they’re using a WAF at all. A good first step is to check the web application’s headers. You can easily do this with the curl command. Just type:

kali> curl -I target.com

In the screenshot above, we can see that the site uses Cloudflare and Qrator’s WAF. Usually, you can spot some hints in the headers that help identify it, like:

The unique transaction tracking ID: X-Qrator-Request-ID or X-Qrator-Req-ID

Server header showing: Server: QRATOR

Internal proxy metadata headers like X-Qrator-IP or X-Qrator-Upstream.

Another way to fingerprint the WAF is through behavior analysis. Here, we’re not just loading a webpage, but we send something that seems a bit malicious. For example, let’s try executing a random HTTP method:

kali> curl -i -X CUSTOMVERB “https://example.com/”

When you run into a 418 status code along with kittenx, it’s usually the edge layer stepping in as a bot-mitigation tool or a WAF block. This means that the incoming request hit a security rule, hit a rate limit, or didn’t pass automated fingerprint checks. Most of the time, you’ll see a 403 status code, which is the classic WAF block. Sometimes you might see other codes like 406, especially with ModSecurity CRS. Some vendors even show their own “Access Denied” HTML page when this happens.

Instead of using curl to trigger different WAF rules manually, a cool tool called WAFW00F can do the identification for you. It starts by sending a normal HTTP request and checking the response to see which WAF solutions it can spot. If that doesn’t work, it sends potentially malicious HTTP requests to figure out which WAF is in play. If that still doesn’t yield results, it looks back at previous responses. It uses straightforward logic to guess whether a WAF or security tool is responding to its efforts. This tool is actually preinstalled on Kali Linux, so you can easily check it out by running:

kali> wafw00f -h

WAFW00F can spot plenty of firewalls. If you want to see the full list, just run this command:

kali> wafw00f -l

You just need to throw a URL in as an argument to get started.

Common WAF Bypass Techniques

Web apps handle lots of encoded text, and problems arise when they decode that text multiple times or in the wrong order compared to what a WAF expects.

For example, double URL encoding can create vulnerabilities. If you encode a single quote twice as %2527, the WAF sees that and thinks it’s safe. But once the app decodes it twice, it turns into a real single quote, slipping past the WAF. This often leads to XSS.

Unicode normalization can also be tricky because characters can appear in different ways. For example, if a WAF looks for < (U+003C) but gets the full-width version (U+FF1C), it won’t catch it. When the app normalizes it back to <, it creates a vulnerability.

Then there is ASCII smuggling, where attackers use invisible Unicode tags (U+E0000 to U+E007F) to replace plain ASCII characters. To the bare eye or even a WAF, it looks like a space in a regular message. But when the application decodes those tags, the hidden payload shows up intact and ready to execute. It is all about hiding real characters behind an invisible disguise.

With the popularity of AI, we also encounter a new type of vulnerability. If an AI model doesn’t have appropriate security guidelines, ASCII manipulations can lead to data poisoning.

Summary

There are tons of ways to get past a WAF without being noticed. In this article, we quickly covered what a WAF is, how it works, and how to identify which WAF you’re dealing with so you can test specific bypass techniques. In a future article, we’ll cover automated solutions. Stay tuned!

The post Introduction to Web Application Firewall (WAF) and Ways to Bypass It first appeared on Hackers Arise.