|
From: Reindl H. <h.r...@th...> - 2018-03-07 19:15:05
|
Am 07.03.2018 um 19:32 schrieb Matt Holdsworth: > 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. you have similar issues with every random file because "<?" also exists in image-files and so on - i gave up check file-uploads for PHP code because of that > 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? it seems to be pointless check repsonse bodies at all when you skip a large amount of them anyways > 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 the put mod_security on the backendserver where it deals with uncompressed responses and leave the reverse proxy alone with compression and content serving |
