How to Troubleshoot Azure WAF

What is Azure Application Gateway?

Azure Application Gateway is a (WAF) that protects web applications against common vulnerabilities and exploitation. It is based on OWASP rules and follows all the rules 3.0 or 2.2.9 of OWASP (Open Web Application Security Project). Microsoft tells us that these rules update themselves, which does not prevent it from having rules that generate false positives. This may also be due to a poorly implemented application, or a perfectible web framework, or perhaps that should be updated. It, therefore, seems useful to know how to debug it if you plan to use it in a project. This article is, therefore, a quick guide for debugging your WAF.

You may also enjoy: Understanding Azure Load Balancing Solutions

Before Troubleshooting

• First, ensure that the "WAF Diagnostics Logs" are enabled. Make sure you have access to the administration console (I know it goes without saying, but it gets better by saying it).
• Second, find out the mode in which the WAF is located:
  • Detection: Monitor and log all threat alerts. You enable the recording of diagnostics for Application Gateway in the Diagnostics section. You must also check that the WAF log is selected and activated. The web application firewall does not block incoming requests when it operates in detection mode.
  • Prevention: Blocks intrusions and attacks detected by the rules. The attacker receives a "403 Unauthorized Access" exception and the connection is terminated. The prevention mode records such attacks in WAF logs.
• Read some documentations :
  • Presentation of the WAF Azure:
  • Troubleshoot Azure Guide :
  • Add an exclusion on the WAF (we would rather add an exclusion than disable a rule) 

Generic Process

1. Generate errors, noting the date, time, and environment (production, pre-production, etc.) of the error occurrence.
2. Go read the logs at these times, using the Azure Monitor @TODO  and take a screenshot.
3. Analyze the logs (which is a JSON file).
   • List of important keywords :
     • requestUri: URI of the request, useful in case the problem occurs each time with the same URI.
     • ruleId: Rule ID
     • ruleGroup: As the name suggests
     • details\file: Name of the file where the rule is defined
     • details\line: File line where the rule is triggered
     • message: Generic wording of the detected problem
     • details\Message: Explanation of the error
     • details\data: Explanation of the error containing the problematic content
   • To find the rule:
     • Go to: https://github.com/SpiderLabs/owasp-modsecurity-crs/tree/v3.0/master/rules
     • Open the file indicated in the parameter details\file and go to the line indicated by the parameter details\line
4. Depending on the case:
   • Either ask the project to make the necessary changes
   • Or add an exclusion, as indicated above at this URL
     • Examples of exclusion :
       • I have a cookie that contains attributes that cause concern :
         • Add an exclusion rule "Request cookie name equals <cookie-attribute-name>"
       • I have a setting on my HTTP call that raises concerns :
         • Add an exclusion rule "Request attribute name equals content"
5. Go back to point 2, as long as you have errors.

Further Reason

Web Application Security: The New Way Forward

Using Logs to Investigate a Web Application Attack