|
From: Matt H. <ma...@ma...> - 2018-03-07 18:32:54
|
Hi! I’m having trouble with false positives in my new nginx+libModSecurity setup, in front of a Ghost blog and running OWASP CRS v3 ruleset. I have the brotli module installed as well as the ModSecurity-nginx connector, and sometimes it seems that libModSecurity gets/analyses brotli-encoded responses. When this happens, I sometimes see false positives in the audit log, e.g. caused by “<?” characters turning up and being detected as PHP code leakage. Or “<%” being detected as another form of code leakage, etc. It seems pointless to perform such analysis on compressed responses (at least, without uncompressing them first), so is there a way I can turn off response body analysis in just these cases? Perhaps I could set a condition of a response header for “Content-Encoding: br” or “Content-Encoding: gzip” being present, as the trigger for the rule? I went to try to create such a rule using the “ctl:responseBodyAccess=Off” action, but the docs say that this action is still TBI (to be implemented) for libModSecurity… Please note: these compressed responses are from the same nginx instance as libModSecurity is installed on, so it’s unfortunately not as easy as “configure your origin server not to compress, and set up your nginx reverse proxy (where libModSecurity is running) to compress instead”. I know for certain that the origin server (Ghost/node.js, in this case) is *not* doing the compression. Any help would be much appreciated! Cheers, Matt |
