Detecting WAFs Through Response Analysis

Hello! Welcome back to our module on advanced server-side vulnerabilities.

In our last lesson, you learned how to escalate a Server-Side Request Forgery (SSRF) vulnerability into a critical compromise by targeting cloud metadata services like AWS IMDS. You saw that the payloads for these attacks often contain specific IP addresses (like the "magic" IP 169.254.169.254) and keywords that a security system might be designed to block. This brings us to a crucial question: What happens when your carefully crafted payload is stopped before it even reaches the application?

Today, we'll meet the first line of defense you will frequently encounter in your penetration testing and bug bounty journey: the Web Application Firewall, or WAF. Our objective is to learn how to identify the presence of a Web Application Firewall (WAF) through response analysis. Mastering WAF detection is a non-negotiable first step. You cannot bypass a defense you don't know is there.

1. Understanding the Adversary: What is a WAF?

A Web Application Firewall (WAF) acts as a security guard for a web application. It sits between the user (and you, the attacker) and the web server, inspecting all incoming HTTP traffic. Its primary job is to identify and block requests that look malicious, such as those carrying SQL injection, XSS, or the SSRF payloads you learned about previously.

To understand how to detect a WAF, you first need a basic grasp of how they operate. The "Awesome-WAF" repository on GitHub provides an excellent and concise introduction.

As you just read, a WAF using a negative model (the most common type for public-facing applications) blocks requests that match a list of known-bad patterns or signatures. Our entire goal in WAF detection is to provoke the WAF into revealing itself by sending a request that triggers one of these signatures.

2. Manual Detection via Response Analysis

The most reliable way to detect a WAF is by sending two types of requests and comparing the server's responses:

1. A benign request (e.g., loading the homepage).
2. A malicious probe request containing a classic, simple attack string (e.g., ?id=<script>alert(1)</script>).

If a WAF is present and active, the responses to these two requests will differ significantly. You can perform this analysis using Burp Suite, which you're already familiar with.

The following video provides a great overview of the key indicators to look for when analyzing these responses.

Let's break down those techniques with some additional context. When comparing your benign and malicious responses, look for these specific changes:

A. The Response Body

This is often the most obvious clue. Many WAFs will return a distinct blocking page when they detect an attack. This page might contain:

• Text like "Access Denied," "Request Blocked," or "Forbidden."
• The name of the WAF vendor (e.g., "Protected by Cloudflare," "Powered by Incapsula").
• An "Incident ID" or "Ray ID" that you can use to report a false positive.

B. HTTP Status Codes

While a benign request might get a 200 OK or 404 Not Found, a WAF blocking your malicious probe might return:

• 403 Forbidden: The most common blocking status.
• 406 Not Acceptable: A classic sign of ModSecurity, a very common open-source WAF.
• 999 No Hacking: A unique and unambiguous code used by the WebKnight WAF.

A change in status code between the two requests is a strong signal.

C. HTTP Response Headers

WAFs often add their own headers to the response or modify existing ones.

• WAF-specific Headers: Look for headers like cf-ray (Cloudflare), X-Sucuri-ID (Sucuri), or X-Iinfo (Imperva).
• Modified Server Header: A WAF might change the Server header from something like Apache to cloudflare or a generic value like nginx. Some WAFs even remove the Server header entirely for blocked requests.

D. Cookies

Some WAFs add their own cookies to manage sessions or track clients.

• For example, seeing a cookie named citrix_ns_id points to a Citrix NetScaler WAF, while incap_ses or visid_incap points to Imperva Incapsula.

The "When WAFs Go Awry" article provides a good summary of these indicators.

3. Automated Detection with wafw00f

While manual analysis gives you the deepest understanding, automated tools can provide a quick first assessment. The industry-standard tool for this is wafw00f. It works by sending a series of benign and malicious probes, much like you would do manually, and then matching the responses against its own large database of WAF fingerprints.

Your background in computer science means you'll appreciate how wafw00f essentially automates the logic of the detection heuristics we've just discussed.

To use wafw00f on Kali Linux, you simply run:
wafw00f -a <target_url>

The -a flag tells it to not stop after the first match and try to find all possible WAFs. While powerful, remember that automated tools can sometimes be wrong or fail to detect a custom or less common WAF. Always be prepared to fall back on your manual analysis skills to confirm the results.

4. A Reference for the Real World

You will encounter dozens of different WAF products in your career. Memorizing every single fingerprint is impossible. The key is to know how to look for them and have a good reference manual.

The "Awesome-WAF" repository you looked at earlier contains an extensive list of fingerprints for a vast number of WAFs.

Test your understanding!

You are testing a web application. You send a normal GET request to / and receive a 200 OK response with a Server: Apache/2.4.29 header.

You then send a request to /?search=' OR 1=1--. The server responds with a 403 Forbidden status code, and the response body contains the text: "Your request was rejected. Please consult with your administrator. Your support ID is 1234567890." The Server header is now missing from this response.

Based on these observations, is a WAF likely present? What are the key pieces of evidence?

Show answer

Yes, a WAF is very likely present.

The key pieces of evidence are:

1. Different Responses: The benign and malicious requests received different responses, which is the primary indicator of an intermediary security device.
2. Status Code Change: The status code changed from 200 OK to 403 Forbidden, a common blocking action for a WAF.
3. Generic Blocking Message: The response body contains a generic block message and a support ID, which is typical behavior for a WAF that wants to hide its identity while still providing a reference for legitimate users who might be blocked by mistake.
4. Header Modification: The Server header, which was present in the benign response, was removed in the blocked response. This is a common technique WAFs use to hide information about the underlying web server during a security event.

Conclusion

Congratulations! You have now learned the foundational skill of WAF detection and fingerprinting. This is a crucial reconnaissance step that separates amateur attackers from professionals. Blindly throwing payloads at a target is noisy and ineffective; identifying the defenses first allows for a much more strategic and surgical approach.

Key Takeaways:

• WAFs are a primary defense against common web attacks, and you must assume they are present on any professional target.
• Detection is based on differential analysis: compare the response to a benign request with the response to a malicious probe.
• Analyze the Four Key Indicators: Look for changes in the response body, status code, headers, and cookies.
• Automated tools like wafw00f are excellent for a quick first look, but always verify their findings with manual techniques.
• Fingerprinting the specific WAF (e.g., Cloudflare, ModSecurity, Imperva) is the ultimate goal, as it informs your strategy for bypassing it.

Next Lesson Preview:

Knowing a WAF is present is half the battle. The other half is getting past it. In our next lesson, we will move from detection to evasion. You will learn how to apply basic WAF bypass techniques for common vulnerabilities like SQLi and XSS, turning those blocked requests into successful exploits.