cancel
Showing results for 
Search instead for 
Did you mean: 

Managing false positives in WAF policy

SalishSeaSecurity
Nimbostratus
Nimbostratus

Situation overview:
1) a Wordpress server that has always been under heavy attack was recently moved behind a F5 WAF
2) the WAF is dropping malicious traffic (thank you F5!)
3) the WAF is also dropping legitimate POSTing of user content with several signatures (Server Side Code Injection, SQL-Injection, Cross Site Scripting (XSS))
4) there is no QA/Test instance; there is no opportunity here for a controlled "learning/staging" process; the server is in production

Example false positive:
One user wants to embed videos on their site. The XSS signature is set off by script tags bracketing a URL pointing to the Vimeo player. The XSS signature fires off during the POSTing of this content to the site.

WAF Suggestion:

Suggested Action: Disable the matched signature on the matched Parameter
Matched Parameter: *
Matched Attack Signature: 200001475 - XSS script tag end (Parameter) (2)

I could choose to click on 'Accept', but I am concerned that the use of a wildcard parameter means script tags will be accepted anywhere, rendering the XSS signature useless. Is that a correct interpetation?

Solution?:
I have whitelisted some known source IP addresses, but that will not satisfy a user base who wants to update content from anywhere at anytime.
There are some Wordpress-specific cookies I can leverage. Looking at the WAF policy Cookie List, however, it appears its focus is to validate as allowed or denied. But that doesn't seem to tie a cookie to a signature. In other words, if you see these valid cookies, then bypass this signature.

It looks like I have two options.

One, write a custom signature to catch legit POSTs (regex search for specific cookies), and disable blocking for this signature.

The other option would be an iRule, like this:

if {HTTP::method is POST and HTTP::URI contains "someURI"} {
if {cookie1="foo" and cookie2="bar"} {
  ASM::disable
}
}

Thank you for taking the time to read this. I welcome any feedback.

6 REPLIES 6

LiefZimmerman
Community Manager
Community Manager

@SalishSeaSecurity - I see you don't have a public answer yet.  The nature of your issue might warrant a Support request but I'll also see if I can find someone avail who knows this tech to take a look.

 

------
Lief ZimmermanLiefZimmerman | @LiefZF5 | DevCentral Community Manager

AaronJB
F5 SIRT
F5 SIRT

You're right in your thinking - if you accept that suggestion, ASM will disable that specific signature on the Wildcard parameter, which is probably not the most ideal move.

Would it be possible to create a specific parameter in the policy and then disable the signature on that? You'd get fine grained control of signatures that way, and only disable the problematic signatures on what is expected to be free-text input (as you've found XSS & SQL injection signatures can be problematic on things like blog content where natural language or mark-up can quite often collide with signatures).

There isn't a mechanism (AFAIK) to tie the enforcement of signatures back to cookies or authenticated users (which, reading between the lines, seems to be what you're aiming for), but something you might like to investigate is the Session Awareness functionality. Using that and the Delayed Blocking feature could allow you to suppress the blocking action for users with valid sessions for a given number of violations in a defined time period; assuming that a user isn't going to sit there submitting content rapid-fire, of course! Would that get you closer?

Thank you for the clarification.  I did look at defining a custom parameter. Unfortunately, it would have been "content".  LOL

I wound up writing an iRule that extracts WordPress user ids from cookies to "class match" them against a data group of authorized users.  

If you have a manageable list of valid users and you trust the authentication, that's a neat fix 🙂

I recently found an old (Wordpress 4.x!) ASM policy template knocking around and took a look at it - although it no longer imports due to schema changes, it is an XML export so you can inspect it manually - and even that policy hasn't defined any specific parameters, just the wildcards present in the base policies, and your problematic signature is enabled in the policy.. but it was a nice thought while it lasted! (Policy is here if you're interested: https://github.com/f5devcentral/f5-asm-policy-templates/blob/master/application_ready_template/WordP...)

PSFletchTheTek
Cirrocumulus
Cirrocumulus

Just to add a commemt of support for f5 Support and the SIRT Team.
They've been brillant helping with ASM/AWAF rules that have got a bit fiddley or complicated when unpicking false positivies and false negatives!

That's great feedback to hear! On behalf of the folks you've dealt with in the past, thank you 🙂