gzip encoding / OWASP_CRS/LEAKAGE/SOURCE_CODE_ASP_JSP

[ArnCo]

Hi,

I encountered a problem on our Apache reverse proxy running ModSecurity (embedded mode). I am currently getting a considerable amount of "OWASP_CRS/LEAKAGE/SOURCE_CODE_ASP_JSP" warnings, as ModSecurity does not seem to recognize gzip content as such (the pattern <% is matched in the encoded content).

Of course, the encoding is disabled between the backend and the reverse Proxy, as content is encoded directly on this very reverse proxy.

I am using the default Ubuntu 14.04 ModSecurity configuration and CRS, repo version.
The VirtualHost configuration is really simple as well,

<VirtualHost *:15080>
  DocumentRoot /var/www/www.<host>.com/html
  ServerName host.com
  ServerAlias www.host.com

  ProxyPreserveHost On

  ProxyPass / http://<host>/ retry=0
  ProxyPassReverse / http://<host>/
</VirtualHost>

I have read a significant amount of (quite old) threads about the problem but each one of them seem to be a dead end.

Waiting for yor feedback,

ArnC

[dusty73]

I had the same problem with nginx + mod_security in reverse proxy mode, simply you have to disable compression on backend side and enable it on frontend side.

If you think about it, it would be a waste of cpu time and memory, mod_security must be as quick as possible.

[ArnCo]

Hi dusty,

Sorry if I have not been clear enough, GZip compression is already disabled on the backend side and enabled on the frontend side.

Cheers,

ArnC

[dusty73]

Ok, the problem is that you have filter with modsec BEFORE the compression happens, from your sample I can't say how to make it. I don't think modsec will ever address this issue, since, as I said, it's a waste of resource and time.

[sbraz]

I'm not sure I understand your reply. Shouldn't apache call modsec before it calls deflate?
It's even mentioned in the documentation of SecDisableBackendCompression:

This directive is not necessary in embedded mode, because ModSecurity performs inspection before response compression takes place.

[dusty73]

But the error happens just because the content is compressed.
Maybe someone else is compressing the output, is this content generated by php or some application server like tomcat? Php has an implicit compression method, triggered by zlib.output_compression flag in configuration, tomcat can compress at connector level the output...

[sbraz]

The content is not compressed. We ran tcpdump to make sure of this. When our server receives a reply from the remote server, it is plain-text. Apache's mod_deflate is the only one compressing data.
Disabling mod_deflate disables compression and mitigates the issue but it isn't a good enough solution.

[sbraz]

It appears that setting SecDisableBackendCompression On solves the issue. However the communication with the backend was not compressed in our case so I don't understand why this option had to be enabled.
It still looks either like a bug or a lack of documentation.

[victorhora]

Please let us know if the issue persists with a newer version of ModSecurity such as 2.9.2 or v3 (libModSecurity)

Also would suggest updating to the latest version (3.x) of OWASP CRS to avoid false positives.

Thanks!