by Thierry de Pauw on
OWASP ModSecurity Core Rule Set maintainer
X: Your WAF broke our application.
Unfortunately, the WAF was not part of the tests. The WAF was only added to the application in production.
first line of defense
- XSS Attack
it does not mean you don't have to write secure code
it is only a safety net in front of your application
it does not stop all attacks
403 - Forbidden: developers fear the WAF because it can also block legitimate traffic
=> the operator will switch off the WAF because the user cannot use the application
We need a better process to add a WAF to an application.
if we use a WAF, we should add the WAF to the tests
ModSecurity: module for web servers to analyse requests
OWASP ModSecurity Core Rule Set (CRS3): a set of request matching rules for ModSecurity
To install a new version of the CRS:
git clone https://github.com/SpiderLabs/owasp-modsecurity-crs.git.ch
cp crs-setup.conf.example crs-setup.conf
this installation covers 80% of web attacks
False Positives: legitimate requests from real users can also be blocked
What could we do to fight False Positive?
- fix the application itself
- if you have one -> Open Issue on GitHub CRS Project
- ModSecurity tuning: partially disable a rule
tutorials on how to tune: https://netnea.com
Official CRS docker container
- reverse proxy
- configurable CRS variables
We do not fully trust the tests => tests can contain False Positive. Developers need to keep the WAF in mind when
No need for WAF, but interested. Make it easy for devs to adopt the WAF via IaC (like OpenShift template that adds a WAF to an app)
WAF makes everyone happy!
- you get an additional layer of defence
- you get a tracing of all the requests your application receives
- you can test it
Docker Hub: owasp/modsecurity-crs