For objective discussion:
We deploy several Web Application Firewalls where I work. I know that one particular on-prem product uses Apache [reverse] Proxy & ModSecurity to match HTTP POST traffic against certain string matches when flagging requests as "SQLi" or "XSS" attack vector attempts. While this works quite well as a bone stock deployment for standard web browsing pages, it facilitates a number of false positives once we introduce web form submissions on our sites.
In particular, some of our web forms allow users to submit HTML code, and further forms allow submission of custom user text. Obviously, our WAF takes issue with the HTML code as an XSS attempt, and flags them false positively.
In a similar but separate scenario, our WAF is also flagging browser's cookie values that may contain URLs, etc - so this applies to traffic that may just be browsing the site and not submitting a form.
I am continually submitting "exceptions" to the SQLi and XSS rules in ModSecurity, basically voiding entire rule IDs or entire form URLs as a result. This is not something I wish to keep in the long term. I'd like to discuss:
- What are your solutions for limiting false positives when employing a WAF for HTTP POST traffic that may contain HTML code & other custom texts?
- Does your WAF also flag & block random cookie values, and have you seen this adversely affect user experience?
We are open to changing the site's code to help resolve this (vs strictly reconfiguring the WAF). We'd like to align our web code (PHP and Ruby) with industry best practices, including for web form submissions.
Afterthought just now: could it be that encoding the user input with JavaScript prior to submission is a reliable - or even a good - solution?
Cheers, SAM
