Azure WAF OWASP 920470 false positive

Hi Vikramaditya,

When I read your post, I understand that you are encountering an issue with Azure Application Gateway's Web Application Firewall (WAF) version 2, which is detecting multipart content-type requests as potential threats with the following message:

Pattern match ^[\w\d/.-+]+(?:\s?;\s?(?:boundary|charset)\s?=\s?['"\w\d.-]+)?$ at REQUEST_HEADERS:content-type.

It appears that the WAF rule in question is scrutinizing the "content-type" header for the presence of the "boundary" or "charset" parameters. In the case of multipart/form-data requests, which are commonly used for file uploads in web applications, the "boundary" parameter is indeed expected to delineate different parts of the multipart request.

Your concern about the rule's strict pattern matching is valid, as it may lead to false positives when the "boundary" parameter is missing or does not precisely adhere to the specified pattern.

To address this issue effectively, I recommend the following approaches:

Rule Customization: Azure Application Gateway WAF provides the capability to customize rules, including the one causing false positives in your scenario. You can explore modifying the rule's regular expression pattern to better align with the legitimate content-type headers used by your application. This approach allows you to fine-tune the rule while preserving security.

Rule Deactivation: In instances where you believe the rule is producing excessive false positives and does not significantly enhance your application's security posture, you may consider temporarily or permanently deactivating it. However, exercise caution when opting for this approach, as it may compromise the overall effectiveness of your WAF.

Engage Azure Support: If you determine that the rule requires adjustments to accommodate valid use cases like multipart/form-data requests, it is advisable to engage Azure Support. They possess the expertise to offer guidance and, if necessary, escalate the matter to the Azure WAF development team for further evaluation and potential rule updates.

When making modifications to WAF rules, it is imperative to strike a balance between security and functionality. Rigorous testing of any rule alterations is essential to ensure that the changes do not inadvertently weaken your security posture.

Should you require further assistance or have additional inquiries, please do not hesitate to reach out. I am committed to assist you in optimizing the security and performance of your Azure-based applications. I hope this helps with your query?

Can you suggest steps for customizing the rule in this case.

Certainly, So when you are customizing a rule in Azure Application Gateway's Web Application Firewall (WAF) to address the issue of false positives in multipart content-type detection involves careful adjustment of the rule's regular expression pattern. I would advise the following steps to guide you through the customization process:

Access the Azure Portal:

• Log in to the Azure Portal with the appropriate credentials.

Navigate to Application Gateway:

• In the left-hand menu, select "All services" and search for "Application Gateways."
• Choose the Application Gateway that you want to customize the WAF rule for.

Access WAF Configuration:

• Inside the Application Gateway settings, select "Web Application Firewall" from the left-hand menu.

Custom Rules:

• Under the "Web Application Firewall" section, locate and click on "Managed rules."

Identify the Rule:

• Find the specific WAF rule that is causing false positives for multipart content-type requests. The rule is likely named or identified with the pattern you provided earlier.

Edit the Rule:

• Click on the rule you want to customize to access its configuration.

Modify the Regular Expression Pattern:

• Within the rule configuration, look for the regular expression pattern that is causing false positives. This pattern may be present in the "Match type" or "Regex pattern" field.
• Adjust the regular expression pattern to better match the legitimate content-type headers used by your application.
• If the rule pattern is excessively strict, consider making it more permissive to avoid flagging valid multipart/form-data requests.

Test the Rule:

• After making changes to the regular expression pattern, it's crucial to thoroughly test the rule. Ensure that it no longer generates false positives while still effectively detecting malicious content-type headers.

1. Save and Apply Changes:
   • Once you are satisfied with the modifications, save your changes within the rule configuration.

Monitor and Fine-Tune:

• Continuously monitor your application's traffic and WAF logs to ensure that the customized rule is functioning as expected. Make further adjustments if necessary.

Documentation and Backup:

• Document the changes made to the rule for future reference.
• Consider creating a backup or snapshot of your WAF configuration before making significant changes to revert to a previous state if issues arise.

Compliance and Security Review:

• If your organization has specific compliance or security requirements, ensure that your custom rule aligns with these standards.

1. Communication:
   • Keep your stakeholders informed about the customization process and the changes made to the WAF rule.

Just bare in mind that customizing WAF rules should be done cautiously to strike the right balance between security and functionality. Regular testing and monitoring are essential to ensure that the rule effectively mitigates threats while avoiding false positives. Additionally, you can consult with your organization's security and compliance teams as needed during the customization process to ensure adherence to policies and standards.

There is no "Edit" configuration option for the OWASP rule.

I apologize for any confusion earlier. As I recall, If you're unable to find an "Edit" configuration option for the OWASP rule in Azure Application Gateway, it's possible that the rule you're trying to modify is one of the predefined OWASP (Open Web Application Security Project) rules that cannot be directly edited or customized within the Azure portal.

In such cases, your options may be more limited when it comes to customizing the rule directly within the portal interface. I can give you some alternative steps you can consider:

Override with a Custom Rule:

• Create a custom rule that takes precedence over the OWASP rule causing false positives. This custom rule should be designed to match and handle the content-type headers more accurately. Ensure that the custom rule is placed above the OWASP rule in the rule order to take effect.

Azure Policy or PowerShell:

• Consider using Azure Policy or Azure PowerShell to create and manage custom WAF rules. These methods provide more flexibility for creating rules, including modifying OWASP rule behavior.

Azure CLI:

• You can also use Azure Command-Line Interface (CLI) to create and manage custom rules. The Azure CLI offers more granular control over rule configuration compared to the portal interface.

Contact Azure Support:

• If the false positives persist and none of the above methods yield a satisfactory solution, it may be advisable to reach out to Azure Support. They can provide more in-depth assistance and potentially engage the Azure WAF development team to address the issue.

When implementing any of these approaches, be sure to thoroughly test your customizations to ensure they effectively address the false positives while maintaining security.

Please note that the specific steps and capabilities available in Azure may evolve over time, so it's a good practice to refer to the latest Azure documentation or consult with Azure Support for the most up-to-date guidance on customizing WAF rule