WAF Fallacies (at least in regards to OWASP ESAPI WAF)

• WAFs add attack surface
• WAFs can create culture problems
• WAFs can't fix business logic vulnerabilities
• WAFs are way too expensive
• WAFs complicate networks

Why fix in ESAPI WAF vs Fix in code?

• Changing in ESAPI WAF is just a text file
• Shorter gap between time discovered and WAF fix vs code fix

Advantages of WAF

• Performance - Only your rules are checked, plus state is already managed by the app server
• Capability - being closer to the app lets us do more
• Process - Rules are closer to application owner, shortening discovery-to-patch time, also fix-to-patch-removal time

Principle: Make common tasks easy, uncommon tasks possible

General virtual patching functionality is easy to understand

Ability to write custom script rules as well "bean-shell-rules"
Fixing Injection Flaws is easy

Can fix business logic flaws with the WAF (missing authentication, missing functional access control, missing data layer access control)

Can add "outbound" security as well

• Add anti-clickjacking header
• Set uniform content-type
• Add HttpOnly flag
• Add secure flag
• Detect outbound information
• Replace outbound information

Takes advantage of early failing to make rules as optimized as possible

Now we see the tool demonstrated with several different vulnerabilities in a real-world application (JForum):

• Cross-Site Scripting Flaw (JForum XSS flaw is unable to be fixed with a WAF because of dynamic URLs)
• Unchecked Redirect
• Add HttpOnly
• Add anti-clickjacking header
• Privilege escalation

3 Different WAF Modes

• Log
• Block
• Redirect

Latency with all of the rules turned on is about 5%.  With selected rules is closer to 0%.  Basically an order of n magnitude where n is the number of rules enabled.  Comes out to milliseconds.