AWS WAF XSS check blocking form with "ON" keyword in form field value

Question

Posting a form with " on" or any word starting with "on" as last word in a form field resulting in an XSS block from aws waf blocked by this rule Body contains a cross-site scripting threat after decoding as URL e.g. "twenty only" or " online" or "check on" all results in XSS block

These seems to be normal words, why it's getting blocked for xss?

but with whitespace at the end it doesn't block e.g. "twenty only " or " online " or "check on " these works

Cyanotype

What is your question? – Scrubland

only, online etc. are normal words. Why aws waf is blocking it I don't Understand? – Cyanotype

For our case, it's blocking a form field with text ending with " one". E.g. "I have one". Strings ending with words like "tone", "bone" etc seems to work fine. – Southsouthwest

Had the same problem. In our case JSON data with +on or /on in HTTP POST was blocked e.g. "/dBV6+ON23vgWCNw==" or "/m18Vm/OneccWI51Yz==" was blocked. We had to disable CrossSiteScripting_BODY in AWSManagedRulesCommonRuleSet to get it working. – Sparker

Answer 1

You can try upgrading to WAFv2, however certain combination with characters "on" +"&" may still cause a false positive. The rule that is causing the problem is XSS on body with URL decoding. So if your formdata is submitted using url-encoding, you could hit a problem. If you submit your form as JSON data or using MIME multipart/form-data it should work. I have 2 application, one with formdata submission with a javascript XHR using fetch api, it uses multipart/form-data and another with JSON data wasn't getting blocked.

Otherwise, you have to tune your XSS rules or set that specific rule to count. I will not post how to tune lest someone lurking here and try to be funny.

What your suggestion of adding a whitespace works as well, the backend can remove the whitespace or leave as it is. A little annoying but it works.

Eaddy

WAFv2 is the same for this issue. This issue is not affected by URL decoding. – Popularly

Answer 2

Just flagging up we got started with WAF last night, and overnight a few dozen legitimate requests were blocked.

Surely enough, each XSS rule had the string "on" in the request body, followed by other characters.

I wonder if it was trying to detect the hundred or so onerror, onload and other javascript events? Feels like it could have been a lot more specific than matching on followed by "some stuff"...

Only solution here seems to be disable this rule for us - it's going to be a constant source of false positives for us otherwise, which makes it worthless.

Poppycock

Answer 3

This is a known problem with the "CrossSiteScripting_BODY" WAFv2 rule provided by AWS as part of the AWSManagedRulesCommonRuleSet ruleset. The rule will block any input that matches on*=*

In a form with multiple inputs, any text that has " on" in it will likely trigger this rule with false positive, e.g. a=three two one&b=something else

In Sept 2021, I complained to AWS Enterprise Support about this clearly broken rule and they replied "Its better to block the request when in doubt than to allow a malicious one", which I strongly disagree with. The support engineer also suggested that I could attempt to whitelist inputs which have triggered this rule, which is totally impractical for any non-trivial web app.

I believe the rule is attempting to block XSS attacks containing scripts like onerror=eval(src), see https://cheatsheetseries.owasp.org/cheatsheets/XSS_Filter_Evasion_Cheat_Sheet.html#waf-bypass-strings-for-xss

I would recommend excluding all the black box CrossSiteScripting rules from your WAF, as they are not fit for purpose.

Popularly