Add all rule labels to events in F5 Rules for AWS WAF - Web exploits OWASP Rules

Forums Technical Forums
, , ,
1

Hi all,

We’re subscribed to the “F5 Rules for AWS WAF - Web exploits OWASP Rules” rules for AWS WAF via Marketplace, and we’re looking at the labels that are added to events passing through the WAF. Currently we see only a single label added to all the events, regardless of which rule triggered a match, the label is:

“labels”: [ { “name”: “awswaf:managed:f5:web-exploits-owasp-rules:OWASP4” } ],

Is there any way to also see the specific rule that triggered, for example the `ruleId`, which we can see in the logs is `rule_Union_Based_AllQueryArguments_Body`.

“terminatingRule”: { “ruleId”: “rule_Union_Based_AllQueryArguments_Body”, “action”: “BLOCK”, “ruleMatchDetails”: null },

This would allow us to better handle false positives for specific rules, without disabling the entire thing.

Does anyone have any ideas? Thanks

2

Hello Ryan,

In this case, the OWASP4 label was created by the terminating rule "rule_Union_Based_AllQueryArguments_Body". More importantly, we’ve received multiple reports of false positives on this rule following a recent update to our rule sets, so we’ve temporarily rolled back the update to further investigate and adjust the rules.

If possible, could you share a few examples of the legitimate requests that were blocked by this rule? That will help us validate the false positive pattern and apply a targeted fix.

Note: With full request logging, you can share information on a rule suspected of blocking a legitimate request by performing the following tasks:

  • Log the HTTP requests that were blocked and the name of the rules that matched them.
  • Make sure that the requests do not contain sensitive information; if they do, mask the sensitive data with ****.

Please don’t hesitate to reach out if there’s anything else we can help with. Thank you.

3

Ah great thanks for your reply! We did see that it had started working again, and couldn’t work out why.

In this case the request that was triggering it was a PATCH request with a JSON body that contained the following:

{“comment”:“An example was \“The Teachers’ Union\””}

4

Thanks for sharing the test case @Ryan_C , it was very helpful in identifying the problematic rule. I wanted to give you an update - We have completed finetuning the OWASP rule set, and will start deploying the updated version across regions starting on Monday, Feburary 23.

Thank you for your patience. Please don’t hesitate if you run into any issues in the future!