Web Application Firewalls Explained

I see this misconception constantly: developers or junior admins slap a Web Application Firewall (WAF) in front of a vulnerable app and…

Web Application Firewalls Explained

I see this misconception constantly: developers or junior admins slap a Web Application Firewall (WAF) in front of a vulnerable app and think they are “secure.”

The article is a conceptual breakdown of why WAFs are distinct from the standard firewalls we all grew up with.

Here is the TL;DR of the WAF fundamentals:

Layer 7 vs. Layer 3

A Network Firewall (Layer 3/4) manages access (who can talk to whom via IP/Port). A WAF (Layer 7) manages content (what they are saying). If you are trying to block SQL Injection with a Network Firewall, you are using the wrong tool.

The models of Security

Negative Security Model (Blacklisting)

This is the default for many. “Allow everything except known attacks.” It’s easier to set up but fails against zero-days.

Positive Security Model (Whitelisting)

“Block everything except known good traffic.” This is infinitely more secure but a nightmare to maintain because every valid input variation needs a rule.

Deployment Architectures

Network-Based (Hardware): Fast, expensive, sits physically in the rack.

Host-Based (Software): Runs on the server (like ModSecurity). Cheaper, but eats your server’s RAM/CPU.

Cloud-Based: The modern standard (like Cloudflare or AWS WAF). Easy to deploy, but you are trusting a third party with your SSL keys.

WAF Fingerprinting

Before launching an attack, you must determine if a WAF is present and, if so, who built it. A WAF often leaves subtle breadcrumbs in the HTTP response.

1. Passive Reconnaissance

Start by inspecting the headers. Standard server banners (like Nginx or Apache) are often replaced or appended with WAF-specific headers (e.g., Server: cloudflare, X-Powered-By: AWS Lambda).

Command Snippet:

# Check headers for WAF signatures 
curl -I http://target.com

2. Active Provocation

If passive headers are scrubbed, you need to poke the bear. Send a “noisy” but harmless payload that matches a known attack signature. If the server responds with a standard 404 Not Found, it’s likely unprotected. If you get a 403 Forbidden or a 406 Not Acceptable, you’ve triggered a rule.

Command Snippet:

# Trigger a standard XSS rule to test response behavior 
curl -I "http://target.com/?q=<script>alert(1)</script>"

# Trigger a Directory Traversal rule
curl -I "http://target.com/admin/../../etc/passwd"

3. Automated Identification

When manual probing is too slow, use dedicated tools. Wafw00f is the industry standard for WAF fingerprinting. It sends a sequence of benign and malicious requests to map the specific behavior of the firewall.

Command Snippet:

# Identify the WAF vendor 
wafw00f https://target.com
Expert Insight: The “Log-Only” Trap:
Many organizations run their WAFs in “Log-Only” mode to avoid breaking legitimate traffic (false positives). During a pentest, if your payloads are executing but you aren’t getting blocked, don’t assume you’re undetected. The Blue Team might be watching your every move in real-time logs, preparing to blacklist your IP at the network level.

Why WAFs Fail (Bypassing)

The video below touches on why WAFs aren’t magic. Simple obfuscation (changing case, adding comments in SQL queries, using different encoding) can often slip past a rigid WAF rule.

The Takeaway

A WAF is a safety net, not a solution. It gives you “virtual patching” time to fix the actual code, but if your underlying logic is broken, a WAF will eventually be bypassed.

THM WAF: Introduction Answers

Answers can be found here