WAF, Processing Phases

As mentioned in the previous post, WAF will evaluate a request in its different phases, these phases are aligned with the way HTTP works, so before diving into the details of WAF, let’s go over some concepts about HTTP.

How does HTTP works? (in brief)

HTTP (hypertext transfer protocol) is the protocol that defines how data is transferred across web connections (mostly over internet) between a client and a server.

Imagine a conversation between two people at a restaurant:

Customer: “Hi, I would like to order a hamburger please“
Waiter: (checks the kitchen to see if hamburgers are available)
If hamburgers are available:
Waiter: “Here is your hamburger!“
If not available:
Waiter: “I’m sorry, we don’t have any hamburgers at the moment“

Just like in a restaurant, HTTP communication has two main parts:

• Request: When you ask for something (“I want a hamburger”) or give something (“Here’s my payment”)
• Response: When you get something back (getting your hamburger) or a message (“Sorry, no hamburgers”)

Each request and response contains:

• Headers: Like the basic information about your order (table number, any allergies, etc.)
• Body: The actual content (the hamburger itself or your payment)

This is exactly how HTTP works:

• Your browser (the customer) asks a website server (the waiter) for a webpage
• The server checks if it has what was requested
• The server sends back a response, which could be the webpage you asked for or a message saying it wasn’t found

Just like people need to speak the same language to understand each other, browsers and servers use HTTP to communicate and exchange information.

Now that we understand how HTTP communication works, let’s see how WAF adds security checks to this process.

Understanding WAF Phases in HTTP Communication

As we learned, HTTP works like a conversation with requests and responses. But when a WAF (Web Application Firewall) is involved, it acts like a security guard checking every part of this conversation.

Let’s continue with our restaurant analogy:

Request Phases (1-2)

• Phase 1: The security guard checks your ID and dress code before you enter (checking request headers)
• Phase 2: They inspect what you’re bringing into the restaurant (checking request body)

Response Phases (3-4)

• Phase 3: They verify what the waiter is about to serve you (checking response headers)
• Phase 4: They ensure the food meets health standards (checking response body)

Phase 5

• Like a security camera recording everything that happened during your visit (logging)

With this basic understanding of WAF’s role, let’s dive deeper into how ModSecurity implements these security checks in each phase.

The 5 Phases of ModSecurity WAF

ModSecurity processes web traffic in 5 distinct phases. Each phase has a specific purpose and runs at different times during the HTTP transaction:

Phase 1: Request Headers

Occurs right after receiving the request headers, before reading the request body.

Example: Checking if suspicious user-agent strings are present

# Block requests with suspicious user-agents
SecRule REQUEST_HEADERS:User-Agent "@contains hack" \
    "id:1,                   # Unique rule identifier
     phase:1,                # Execute in Phase 1 (Request Headers)
     deny,                   # Action: Block the request
     status:403,            # Return HTTP 403 Forbidden
     msg:'Suspicious User-Agent detected',  # Log message
     log,                   # Enable logging
     severity:'CRITICAL'"   # Set alert severity

Phase 2: Request Body

Happens after the request body has been read but before it’s forwarded to the application. Example: Detecting SQL injection attempts in POST data

# Check for SQL injection in form fields
SecRule REQUEST_BODY "@contains SELECT" \
    "id:2,phase:2,deny,msg:'Potential SQL injection attempt'"

Phase 3: Response Headers

Executes right after the application generates response headers.

Example: Removing server version information

# Remove detailed server information
SecRule RESPONSE_HEADERS:Server "^Apache/2" \
    "id:3,phase:3,replace:Server: 'WebServer'"

Phase 4: Response Body

Runs after receiving the response body from the application.

Example: Preventing sensitive data leakage

# Check for credit card numbers in responses
SecRule RESPONSE_BODY "@rx \d{4}-\d{4}-\d{4}-\d{4}" \
    "id:4,phase:4,deny,msg:'Credit card data leak detected'"

Phase 5: Logging

Executes after the response is sent to the client. Perfect for logging and cleanup tasks.

Example: Logging high-risk transactions

# Log requests with high anomaly scores
SecRule TX:ANOMALY_SCORE "@ge 5" \
    "id:5,phase:5,pass,log,msg:'High risk activity detected'"

Each phase happens in sequence, allowing for comprehensive security checks throughout the entire HTTP transaction.

Why Understanding WAF Phases Matters

Understanding these phases is crucial for several reasons:

1. Better Security Implementation
   Knowing how each phase works helps you put your security rules in the right place. Think about it - if you want to block bad IPs, why wait until Phase 4 when you can stop them right away in Phase 1? Makes sense, right?

2. Performance Optimization
   This is about working smarter, not harder. For example, why would you look for credit card numbers in request headers (Phase 1) when they usually show up in response bodies (Phase 4)? Understanding phases helps you put your security checks exactly where they need to be.

3. Troubleshooting
   When something goes wrong (and trust me, it will), knowing your phases makes life so much easier. If you know a rule triggered in Phase 2, you can focus on the request body instead of pulling your hair out checking everything else.

4. Rule Development
   Each phase has its own set of tools (variables) you can use. If you try to use RESPONSE_BODY in Phase 1, it’s like trying to read a message that hasn’t been written yet - it just won’t work!

Remember: These phases aren’t just random steps - they follow the same path as your HTTP traffic. Understanding them helps you build better, faster, and more effective security rules.

Until the next post!