WAF Helps Keep Your Azure App Available. Mostly.

OWASP 3.0 Rules in Azure Portal

Azure Application Gateway has an optional feature called Web Application Firewall (WAF), which affords protection against numerous types of attacks against your Azure web app. The functionality and features of App Gateway and WAF are well documented online, but recently a colleague discovered a less obvious aspect that's worth sharing.

If the WAF feature is enabled in your App Gateway, a set of filtering rules is applied. WAF rules are visible and configurable in the Azure Portal, as seen in the adjacent image. You select either OWASP 2.x or 3.x rule sets. The list of rules is large and detailed, as show in the adjacent image for OWASP 3.0.

The Problem

I always advocate working with technology to discover undocumented aspects, product limits, and the like. This is how you build domain expertise. Jorge Cotillo was doing just that, using WAF Prevention mode with OWASP 3.0, and he stumbled on an interesting issue with a customer.

In Prevention mode, WAF will return HTTP 403 to callers if a rule violation is detected. The customer has a legacy app that uses calls webresource.axd to access resources, and legitimate access attempts ran afoul of those rules. A very important business function was blocked.

The problem was traced by first noticing the broken application functionality, then by looking into the WAF logs to correlate blocked requests to access attempts by the app.

The Solution

Note: Exercise caution before disabling any WAF protection rules, as this can render your web app prone to certain attacks.

OWASP 3.0 Rule 92440

Access to the .AXD was restored by disabling rule 920440, "URL file extension is restricted by policy".

With .AXD access restored, Jorge then discovered that a WCF service was also blocked. After research, the following rules were disabled and the WCF service became accessible. The service was not using transport security.

• 920300 - Request Missing an Accept Header
• 920320 - Missing User Agent Header
• 920420 - Request content type is not allowed by policy

Conclusion

Security Effectiveness vs. "Tightness"

Security is essential on the internet, and should be part of any internet-facing web app / API from the get-go. But remember that a primary function of security is to keep the business function running and usable by customers. Balance is required to insure that goal is met.

This situation is one I've seen before, where implementing a security technology or policy to safeguard computer-based business function actually prevented its use. Security is not a linear function, it is - as are so many aspects of technology - a bell curve (or approximation of such). Crank up the "security" too far (say, to 11) and business protection actually goes down. The irony is that the business function is very secure, because it's inaccessible.