Thread: [mod-security-users] issue with response body processing

Brought to you by: victorhora, zimmerletw

mod-security-users

[mod-security-users] issue with response body processing

From: Alex <adm...@ah...> - 2015-10-19 02:55:47

Hi All,

I having a problem with rules that involve inspection of the response 
body. Some info about the server:

Modsec version: 2.2.9
Ruleset version: "OWASP_CRS/2.2.9"
Web Server: Apache 2.4
OS: Debian 8 x64 (using modsec and crs from the debian repository).

The below rule keeps tripping (snippet from audit log):


--d123de0b-H--
Message: Match of "rx 
(?:\\b(?:(?:i(?:nterplay|hdr|d3)|m(?:ovi|thd)|r(?:ar!|iff)|(?:ex|jf)if|f(?:lv|ws)|varg|cws)\\b|gif)|B(?:%pdf|\\.ra)\\b)" 
against "RESPONSE_BODY" required. [file "
/etc/modsecurity/activated_rules/modsecurity_crs_50_outbound.conf"] 
[line "39"] [id "970903"] [rev "2"] [msg "ASP/JSP source code leakage"] 
[data "Matched Data: <% found within RESPONS
E_BODY: 
\x1f\x8b\x08\x00\x00\x00\x00\x00\x00\x03\xed}\xfbw\xdb6\xd2\xe8\xcf\xf69\xfd\x1f\xb0ln%\xb7\xd6\xd3\xcf\xc8\x8f\xae7NZ\xdf\xbc\xfc\xd9n\xb7\xdf\xa699\x94\x08Y\x8c)R%);J\xae\xff
\xf7;3\x00\xf8\xa6D\xca\x92\x9dt\xad\xd3\xc6\x12\x09\x0c\x06\x83\xc1\xbc0\x00\xbe[\xdd\xff\xc7\xf1\xdbg\x17\xff{\xfa\x9c\x0d\xfc\xa1u\xf8\xdd\xea>\xfee\x96n_\x1eh\xdc\xd6\xe0\x09\x83\x
cf\xfe\x80\xeb\x86\xfcN\xbf\x87\xdc\xd7\xa1\x8a?\xaa\xf1\xbf\xc6\xe6\xf5\x81\xd6sl\x9f\xdb~\xcd\x9f\x8c\..."] 
[severity "ERROR"] [ver "OWASP_CRS/2.2.9"] [maturity "9"] [accuracy "9"] 
[
tag "OWASP_CRS/LEAKAGE/SOURCE_CODE_ASP_JSP"] [tag "WASCTC/WASC-13"] [tag 
"OWASP_TOP_10/A6"] [tag "PCI/6.5.6"]
Message: Access denied with code 403 (phase 4). [file 
"/etc/modsecurity/activated_rules/modsecurity_crs_59_outbound_blocking.conf"] 
[line "24"] [id "981200"] [msg "Outbound Anomaly Sco
re Exceeded (score 4): Last Matched Message: ASP/JSP source code 
leakage"] [data "Last Matched Data: <%"]
Message: Warning. Operator GE matched 4 at TX:outbound_anomaly_score. 
[file 
"/etc/modsecurity/activated_rules/modsecurity_crs_60_correlation.conf"] 
[line "40"] [id "981205"] [msg "Outb
ound Anomaly Score Exceeded (score 4): ASP/JSP source code leakage"]
Action: Intercepted (phase 4)
Stopwatch: 1444624874809492 772556 (- - -)
Stopwatch2: 1444624874809492 772556; combined=14697, p1=470, p2=12435, 
p3=3, p4=1679, p5=110, sr=82, sw=0, l=0, gc=0
Response-Body-Transformed: Dechunked
Producer: ModSecurity for Apache/2.8.0 (http://www.modsecurity.org/); 
OWASP_CRS/2.2.9.
Server: Apache/2.4.10 (Debian)
Engine-Mode: "ENABLED"
----------------------------


This rule is being tripped in error. The response body in the audit log 
seems to be compressed and is all garbage, it just happens that there 
are probably a sequence of characters in that data that trips this rule.

Setting "SecDisableBackendCompression Off" seems to fix this but 
ultimately disables compression all together in apache.. which is not 
good news since I'd like to keep compression on for our site visitors. 
Is there any way to have modsecurity look at the response body prior to 
apache compressing it? Googling for solutions really only turned up 
articles suggesting the SecDisableBackendCompression trick.. Surely 
there is a better way to deal with this and still have the best of both 
worlds.

Look forward to suggestions.

Cheers,
Alex.

Re: [mod-security-users] issue with response body processing

From: Christian F. <chr...@ti...> - 2015-10-19 03:23:59

Alex,

Your problem is a typical one.

Are you running ModSec on a reverse proxy or on the application
server itself?

The SecDisableBackendCompression is the standard way to handle it
and it works just fine on a Reverse Proxy (if the backend
application is well-behaving).

The idea is to have the backend send the response uncompressed
to the apache reverse proxy and then have apache do the
compression of the response before it is sent to the client.
This can be done via
LoadModule deflate_module modules/mod_deflate.so
...
SetOutputFilter DEFLATE

You may want to look into AddOutputFilterByType, but this could
potentially open a can of worms with timing issues and stuff.
This has been a topic in the developer community lately and maybe
we will see an improvement. My personal approach for selective
compression of certain content type is to work with the following
construction:

The deflate module checks the env variable no-gzip. We check the
content type and set an additional env variable do-gzip if it is
something we want to compress. It if it is not set (number of ENV
variables set equals 0), we do not want compression and set the
no-gzip variable.

Good luck,

Christian

--
The scientist has marched in and taken the place of the poet. But one
day somebody will find the solution to the problems of the world and
remember, it will be a poet, not a scientist.
-- Frank Lloyd Wright

Re: [mod-security-users] issue with response body processing

From: Alex <adm...@ah...> - 2015-10-19 03:52:17

Hi Christian,

Thank you for the followup. There is no reverse proxy setup in place, 
modsecurity is running on the application server. Does this change 
anything?

Kind Regards,
Alex.



On 2015-10-19 14:23, Christian Folini wrote:

> Alex,
> 
> Your problem is a typical one.
> 
> Are you running ModSec on a reverse proxy or on the application
> server itself?
> 
> The SecDisableBackendCompression is the standard way to handle it
> and it works just fine on a Reverse Proxy (if the backend
> application is well-behaving).
> 
> The idea is to have the backend send the response uncompressed
> to the apache reverse proxy and then have apache do the
> compression of the response before it is sent to the client.
> This can be done via
> LoadModule              deflate_module          modules/mod_deflate.so
> ...
> SetOutputFilter         DEFLATE
> 
> You may want to look into AddOutputFilterByType, but this could
> potentially open a can of worms with timing issues and stuff.
> This has been a topic in the developer community lately and maybe
> we will see an improvement. My personal approach for selective
> compression of certain content type is to work with the following
> construction:
> 
> SecRule RESPONSE_HEADERS:Content-Type   
> "^(text/html|text/plain|text/xml|text/css|text/javascript|application/javascript)$" 
> "phase:3,pass,nolog,id:1,t:lowercase,setenv:do-gzip"
> SecRule &ENV:do-gzip "@eq 0" "phase:3,pass,nolog,id:2,setenv:no-gzip"
> 
> The deflate module checks the env variable no-gzip. We check the
> content type and set an additional env variable do-gzip if it is
> something we want to compress. It if it is not set (number of ENV
> variables set equals 0), we do not want compression and set the
> no-gzip variable.
> 
> Good luck,
> 
> Christian

Re: [mod-security-users] issue with response body processing

From: Christian F. <chr...@ti...> - 2015-10-19 04:03:57

Hello,

On Mon, Oct 19, 2015 at 02:52:03PM +1100, Alex wrote:
> Thank you for the followup. There is no reverse proxy setup in place, 
> modsecurity is running on the application server. Does this change 
> anything?

Well, the doc says:

"This directive is necessary in reverse proxy mode when the backend
servers support response compression, but you wish to inspect response
bodies. Unless you disable backend compression, ModSecurity will only
see compressed content, which is not very useful. This directive is not
necessary in embedded mode, because ModSecurity performs inspection
before response compression takes place."

So technically, you should not have your problem in the first place.
So maybe it is not the compression after all. The match in your
response body suggests binary, but not quite.
What is this actually? Request and Response headers would be welcome.

Ahoj,

Christian

-- 
When there are too many policemen, there can be no liberty. When there
are too many soldiers, there can be no peace. When there are too many
lawyers, there can be no justice.
-- Lin Yutang

Re: [mod-security-users] issue with response body processing

From: Alex <adm...@ah...> - 2015-10-19 04:23:24

Hi Christian, 

What appears in the audit log (which appears to dump the response body)
is a load of binary gibberish. If I switch off the compression,
javascript code is in the response body (and is logged and doesnt cause
an issue), which is fine. I assume embedded mode is what I should have
since it is a stock install of apache and modsecurity. Theres no
proxying going on that I am aware of. 

Something is causing modsecurity not to make the inspection take place
before compression. 

I'll see if I can get some more info for the list if that is going to
help :) 

Cheers 

Alex. 

On 2015-10-19 15:03, Christian Folini wrote: 

> Hello,
> 
> On Mon, Oct 19, 2015 at 02:52:03PM +1100, Alex wrote: 
> 
>> Thank you for the followup. There is no reverse proxy setup in place, 
>> modsecurity is running on the application server. Does this change 
>> anything?
> 
> Well, the doc says:
> 
> "This directive is necessary in reverse proxy mode when the backend
> servers support response compression, but you wish to inspect response
> bodies. Unless you disable backend compression, ModSecurity will only
> see compressed content, which is not very useful. This directive is not
> necessary in embedded mode, because ModSecurity performs inspection
> before response compression takes place."
> 
> So technically, you should not have your problem in the first place.
> So maybe it is not the compression after all. The match in your
> response body suggests binary, but not quite.
> What is this actually? Request and Response headers would be welcome.
> 
> Ahoj,
> 
> Christian

Re: [mod-security-users] issue with response body processing

From: Alex <adm...@ah...> - 2015-10-19 23:24:11

Hi Christian,

Is this what you were wanting to see? (snippet from audit log):


--fb5c277e-A--
[20/Oct/2015:10:14:15 +1100] ViV5RnrKQOUAAAM@TmMAAAAM 59.IP.IP.IP 41052 
122.IP.IP.IP 443
--fb5c277e-B--
GET /the/getrequest/index.php/something/something/1183 HTTP/1.1
Host: the.host.name
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:41.0) 
Gecko/20100101 Firefox/41.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Referer: https://host.name/some/folder/index.php/blah/blah
Cookie: <snip>
Connection: keep-alive

--fb5c277e-F--
HTTP/1.1 403 Forbidden
Last-Modified: Tue, 18 Jun 2013 03:29:32 GMT
ETag: "a67-4df6552483f00"
Accept-Ranges: bytes
Content-Length: 2663
X-Powered-By: A flock of seagulls
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
X-Frame-Options: sameorigin
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html

--fb5c277e-E--
�}�w�6����9��ln%����ȏ�7NZ߼��n�ߦ99Y�)R%);J���;3��Dʒ�t���
<snip loads of garbage>


--fb5c277e-H--
Message: Match of "rx 
(?:\\b(?:(?:i(?:nterplay|hdr|d3)|m(?:ovi|thd)|r(?:ar!|iff)|(?:ex|jf)if|f(?:lv|ws)|varg|cws)\\b|gif)|B(?:%pdf|\\.ra)\\b)" 
against "RESPONSE_BODY" required. [file 
"/etc/modsecurity/activated_rules/modsecurity_crs_50_outbound.conf"] 
[line "39"] [id "970903"] [rev "2"] [msg "ASP/JSP source code leakage"] 
[data "Matched Data: <% found within RESPONSE_BODY: 
\x1f\x8b\x08\x00\x00\x00\x00\x00\x00\x03\xed}\xfbw\xdb6\xd2\xe8\xcf\xf69\xfd\x1f\xb0ln%\xb7\xd6\xd3\xcf\xc8\x8f\xae7NZ\xdf\xbc\xfc\xd9n\xb7\xdf\xa699\x94\x08Y\x8c)R%);J\xae\xff\xf7;3\x00\xf8\xa6D\xca\x92\x9dt\xad\xd3\xc6\x12\x09\x0c\x06\x83\xc1\xbc0\x00\xbe[\xdd\xff\xc7\xf1\xdbg\x17\xff{\xfa\x9c\x0d\xfc\xa1u\xf8\xdd\xea>\xfee\x96n_\x1eh\xdc\xd6\xe0\x09\x83\xcf\xfe\x80\xeb\x86\xfcN\xbf\x87\xdc\xd7\xa1\x8a?\xaa\xf1\xbf\xc6\xe6\xf5\x81\xd6sl\x9f\xdb~\xcd\x9f\x8c\..."] 
[severity "ERROR"] [ver "OWASP_CRS/2.2.9"] [maturity "9"] [accuracy "9"] 
[tag "OWASP_CRS/LEAKAGE/SOURCE_CODE_ASP_JSP"] [tag "WASCTC/WASC-13"] 
[tag "OWASP_TOP_10/A6"] [tag "PCI/6.5.6"]
Message: Access denied with code 403 (phase 4). [file 
"/etc/modsecurity/activated_rules/modsecurity_crs_59_outbound_blocking.conf"] 
[line "24"] [id "981200"] [msg "Outbound Anomaly Score Exceeded (score 
4): Last Matched Message: ASP/JSP source code leakage"] [data "Last 
Matched Data: <%"]
Message: Warning. Operator GE matched 4 at TX:outbound_anomaly_score. 
[file 
"/etc/modsecurity/activated_rules/modsecurity_crs_60_correlation.conf"] 
[line "40"] [id "981205"] [msg "Outbound Anomaly Score Exceeded (score 
4): ASP/JSP source code leakage"]
Action: Intercepted (phase 4)
Stopwatch: 1445296454982648 990282 (- - -)
Stopwatch2: 1445296454982648 990282; combined=16528, p1=334, p2=12802, 
p3=4, p4=3230, p5=157, sr=61, sw=1, l=0, gc=0
Response-Body-Transformed: Dechunked
Producer: ModSecurity for Apache/2.8.0 (http://www.modsecurity.org/); 
OWASP_CRS/2.2.9.
Server: Apache/2.4.10 (Debian)
Engine-Mode: "ENABLED

------------------

We're definitely running modsecurity in an embedded mode scenario.


Kind Regards,
Alex R.


On 2015-10-19 15:03, Christian Folini wrote:

> Hello,
> 
> On Mon, Oct 19, 2015 at 02:52:03PM +1100, Alex wrote:
> 
>> Thank you for the followup. There is no reverse proxy setup in place,
>> modsecurity is running on the application server. Does this change
>> anything?
> 
> Well, the doc says:
> 
> "This directive is necessary in reverse proxy mode when the backend
> servers support response compression, but you wish to inspect response
> bodies. Unless you disable backend compression, ModSecurity will only
> see compressed content, which is not very useful. This directive is not
> necessary in embedded mode, because ModSecurity performs inspection
> before response compression takes place."
> 
> So technically, you should not have your problem in the first place.
> So maybe it is not the compression after all. The match in your
> response body suggests binary, but not quite.
> What is this actually? Request and Response headers would be welcome.
> 
> Ahoj,
> 
> Christian

Re: [mod-security-users] issue with response body processing

From: Alex <adm...@ah...> - 2015-10-20 03:29:30

Could it be this issue?:

https://github.com/SpiderLabs/ModSecurity/issues/944

On 2015-10-20 10:23, Alex wrote:

> Hi Christian,
> 
> Is this what you were wanting to see? (snippet from audit log):
> 
> --fb5c277e-A--
> [20/Oct/2015:10:14:15 +1100] ViV5RnrKQOUAAAM@TmMAAAAM 59.IP.IP.IP 41052
> 122.IP.IP.IP 443
> --fb5c277e-B--
> GET /the/getrequest/index.php/something/something/1183 HTTP/1.1
> Host: the.host.name
> User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:41.0)
> Gecko/20100101 Firefox/41.0
> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
> Accept-Language: en-US,en;q=0.5
> Accept-Encoding: gzip, deflate
> DNT: 1
> Referer: https://host.name/some/folder/index.php/blah/blah
> Cookie: <snip>
> Connection: keep-alive
> 
> --fb5c277e-F--
> HTTP/1.1 403 Forbidden
> Last-Modified: Tue, 18 Jun 2013 03:29:32 GMT
> ETag: "a67-4df6552483f00"
> Accept-Ranges: bytes
> Content-Length: 2663
> X-Powered-By: A flock of seagulls
> X-Content-Type-Options: nosniff
> X-XSS-Protection: 1; mode=block
> X-Frame-Options: sameorigin
> Keep-Alive: timeout=5, max=100
> Connection: Keep-Alive
> Content-Type: text/html
> 
> --fb5c277e-E--
> �}�w�6����9��ln%����ȏ�7NZ߼��n�ߦ99Y�)R%);J���;3��Dʒ�t���
> <snip loads of garbage>
> 
> --fb5c277e-H--
> Message: Match of "rx
> (?:\\b(?:(?:i(?:nterplay|hdr|d3)|m(?:ovi|thd)|r(?:ar!|iff)|(?:ex|jf)if|f(?:lv|ws)|varg|cws)\\b|gif)|B(?:%pdf|\\.ra)\\b)"
> against "RESPONSE_BODY" required. [file
> "/etc/modsecurity/activated_rules/modsecurity_crs_50_outbound.conf"]
> [line "39"] [id "970903"] [rev "2"] [msg "ASP/JSP source code leakage"]
> [data "Matched Data: <% found within RESPONSE_BODY:
> \x1f\x8b\x08\x00\x00\x00\x00\x00\x00\x03\xed}\xfbw\xdb6\xd2\xe8\xcf\xf69\xfd\x1f\xb0ln%\xb7\xd6\xd3\xcf\xc8\x8f\xae7NZ\xdf\xbc\xfc\xd9n\xb7\xdf\xa699\x94\x08Y\x8c)R%);J\xae\xff\xf7;3\x00\xf8\xa6D\xca\x92\x9dt\xad\xd3\xc6\x12\x09\x0c\x06\x83\xc1\xbc0\x00\xbe[\xdd\xff\xc7\xf1\xdbg\x17\xff{\xfa\x9c\x0d\xfc\xa1u\xf8\xdd\xea>\xfee\x96n_\x1eh\xdc\xd6\xe0\x09\x83\xcf\xfe\x80\xeb\x86\xfcN\xbf\x87\xdc\xd7\xa1\x8a?\xaa\xf1\xbf\xc6\xe6\xf5\x81\xd6sl\x9f\xdb~\xcd\x9f\x8c\..."]
> [severity "ERROR"] [ver "OWASP_CRS/2.2.9"] [maturity "9"] [accuracy 
> "9"]
> [tag "OWASP_CRS/LEAKAGE/SOURCE_CODE_ASP_JSP"] [tag "WASCTC/WASC-13"]
> [tag "OWASP_TOP_10/A6"] [tag "PCI/6.5.6"]
> Message: Access denied with code 403 (phase 4). [file
> "/etc/modsecurity/activated_rules/modsecurity_crs_59_outbound_blocking.conf"]
> [line "24"] [id "981200"] [msg "Outbound Anomaly Score Exceeded (score
> 4): Last Matched Message: ASP/JSP source code leakage"] [data "Last
> Matched Data: <%"]
> Message: Warning. Operator GE matched 4 at TX:outbound_anomaly_score.
> [file
> "/etc/modsecurity/activated_rules/modsecurity_crs_60_correlation.conf"]
> [line "40"] [id "981205"] [msg "Outbound Anomaly Score Exceeded (score
> 4): ASP/JSP source code leakage"]
> Action: Intercepted (phase 4)
> Stopwatch: 1445296454982648 990282 (- - -)
> Stopwatch2: 1445296454982648 990282; combined=16528, p1=334, p2=12802,
> p3=4, p4=3230, p5=157, sr=61, sw=1, l=0, gc=0
> Response-Body-Transformed: Dechunked
> Producer: ModSecurity for Apache/2.8.0 (http://www.modsecurity.org/);
> OWASP_CRS/2.2.9.
> Server: Apache/2.4.10 (Debian)
> Engine-Mode: "ENABLED
> 
> ------------------
> 
> We're definitely running modsecurity in an embedded mode scenario.
> 
> Kind Regards,
> Alex R.
> 
> On 2015-10-19 15:03, Christian Folini wrote:
> 
> Hello,
> 
> On Mon, Oct 19, 2015 at 02:52:03PM +1100, Alex wrote:
> 
> Thank you for the followup. There is no reverse proxy setup in place,
> modsecurity is running on the application server. Does this change
> anything?
> Well, the doc says:
> 
> "This directive is necessary in reverse proxy mode when the backend
> servers support response compression, but you wish to inspect response
> bodies. Unless you disable backend compression, ModSecurity will only
> see compressed content, which is not very useful. This directive is not
> necessary in embedded mode, because ModSecurity performs inspection
> before response compression takes place."
> 
> So technically, you should not have your problem in the first place.
> So maybe it is not the compression after all. The match in your
> response body suggests binary, but not quite.
> What is this actually? Request and Response headers would be welcome.
> 
> Ahoj,
> 
> Christian

------------------------------------------------------------------------------
_______________________________________________
mod-security-users mailing list
mod...@li...
https://lists.sourceforge.net/lists/listinfo/mod-security-users
Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
http://www.modsecurity.org/projects/commercial/rules/
http://www.modsecurity.org/projects/commercial/support/

Re: [mod-security-users] issue with response body processing

From: Christian F. <chr...@ti...> - 2015-10-20 04:17:56

Alex,

On Tue, Oct 20, 2015 at 02:29:11PM +1100, Alex wrote:
> https://github.com/SpiderLabs/ModSecurity/issues/944

Exactly. That's why I said it has been a topic last week
in the developer community meeting.

Sorry for the bad news. However, the good news is,
it's being fixed now.

Ahoj,

Christian



> 
> On 2015-10-20 10:23, Alex wrote:
> 
> > Hi Christian,
> > 
> > Is this what you were wanting to see? (snippet from audit log):
> > 
> > --fb5c277e-A--
> > [20/Oct/2015:10:14:15 +1100] ViV5RnrKQOUAAAM@TmMAAAAM 59.IP.IP.IP 41052
> > 122.IP.IP.IP 443
> > --fb5c277e-B--
> > GET /the/getrequest/index.php/something/something/1183 HTTP/1.1
> > Host: the.host.name
> > User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:41.0)
> > Gecko/20100101 Firefox/41.0
> > Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
> > Accept-Language: en-US,en;q=0.5
> > Accept-Encoding: gzip, deflate
> > DNT: 1
> > Referer: https://host.name/some/folder/index.php/blah/blah
> > Cookie: <snip>
> > Connection: keep-alive
> > 
> > --fb5c277e-F--
> > HTTP/1.1 403 Forbidden
> > Last-Modified: Tue, 18 Jun 2013 03:29:32 GMT
> > ETag: "a67-4df6552483f00"
> > Accept-Ranges: bytes
> > Content-Length: 2663
> > X-Powered-By: A flock of seagulls
> > X-Content-Type-Options: nosniff
> > X-XSS-Protection: 1; mode=block
> > X-Frame-Options: sameorigin
> > Keep-Alive: timeout=5, max=100
> > Connection: Keep-Alive
> > Content-Type: text/html
> > 
> > --fb5c277e-E--
> > �}�w�6����9��ln%����ȏ�7NZ߼��n�ߦ99Y�)R%);J���;3��Dʒ�t���
> > <snip loads of garbage>
> > 
> > --fb5c277e-H--
> > Message: Match of "rx
> > (?:\\b(?:(?:i(?:nterplay|hdr|d3)|m(?:ovi|thd)|r(?:ar!|iff)|(?:ex|jf)if|f(?:lv|ws)|varg|cws)\\b|gif)|B(?:%pdf|\\.ra)\\b)"
> > against "RESPONSE_BODY" required. [file
> > "/etc/modsecurity/activated_rules/modsecurity_crs_50_outbound.conf"]
> > [line "39"] [id "970903"] [rev "2"] [msg "ASP/JSP source code leakage"]
> > [data "Matched Data: <% found within RESPONSE_BODY:
> > \x1f\x8b\x08\x00\x00\x00\x00\x00\x00\x03\xed}\xfbw\xdb6\xd2\xe8\xcf\xf69\xfd\x1f\xb0ln%\xb7\xd6\xd3\xcf\xc8\x8f\xae7NZ\xdf\xbc\xfc\xd9n\xb7\xdf\xa699\x94\x08Y\x8c)R%);J\xae\xff\xf7;3\x00\xf8\xa6D\xca\x92\x9dt\xad\xd3\xc6\x12\x09\x0c\x06\x83\xc1\xbc0\x00\xbe[\xdd\xff\xc7\xf1\xdbg\x17\xff{\xfa\x9c\x0d\xfc\xa1u\xf8\xdd\xea>\xfee\x96n_\x1eh\xdc\xd6\xe0\x09\x83\xcf\xfe\x80\xeb\x86\xfcN\xbf\x87\xdc\xd7\xa1\x8a?\xaa\xf1\xbf\xc6\xe6\xf5\x81\xd6sl\x9f\xdb~\xcd\x9f\x8c\..."]
> > [severity "ERROR"] [ver "OWASP_CRS/2.2.9"] [maturity "9"] [accuracy 
> > "9"]
> > [tag "OWASP_CRS/LEAKAGE/SOURCE_CODE_ASP_JSP"] [tag "WASCTC/WASC-13"]
> > [tag "OWASP_TOP_10/A6"] [tag "PCI/6.5.6"]
> > Message: Access denied with code 403 (phase 4). [file
> > "/etc/modsecurity/activated_rules/modsecurity_crs_59_outbound_blocking.conf"]
> > [line "24"] [id "981200"] [msg "Outbound Anomaly Score Exceeded (score
> > 4): Last Matched Message: ASP/JSP source code leakage"] [data "Last
> > Matched Data: <%"]
> > Message: Warning. Operator GE matched 4 at TX:outbound_anomaly_score.
> > [file
> > "/etc/modsecurity/activated_rules/modsecurity_crs_60_correlation.conf"]
> > [line "40"] [id "981205"] [msg "Outbound Anomaly Score Exceeded (score
> > 4): ASP/JSP source code leakage"]
> > Action: Intercepted (phase 4)
> > Stopwatch: 1445296454982648 990282 (- - -)
> > Stopwatch2: 1445296454982648 990282; combined=16528, p1=334, p2=12802,
> > p3=4, p4=3230, p5=157, sr=61, sw=1, l=0, gc=0
> > Response-Body-Transformed: Dechunked
> > Producer: ModSecurity for Apache/2.8.0 (http://www.modsecurity.org/);
> > OWASP_CRS/2.2.9.
> > Server: Apache/2.4.10 (Debian)
> > Engine-Mode: "ENABLED
> > 
> > ------------------
> > 
> > We're definitely running modsecurity in an embedded mode scenario.
> > 
> > Kind Regards,
> > Alex R.
> > 
> > On 2015-10-19 15:03, Christian Folini wrote:
> > 
> > Hello,
> > 
> > On Mon, Oct 19, 2015 at 02:52:03PM +1100, Alex wrote:
> > 
> > Thank you for the followup. There is no reverse proxy setup in place,
> > modsecurity is running on the application server. Does this change
> > anything?
> > Well, the doc says:
> > 
> > "This directive is necessary in reverse proxy mode when the backend
> > servers support response compression, but you wish to inspect response
> > bodies. Unless you disable backend compression, ModSecurity will only
> > see compressed content, which is not very useful. This directive is not
> > necessary in embedded mode, because ModSecurity performs inspection
> > before response compression takes place."
> > 
> > So technically, you should not have your problem in the first place.
> > So maybe it is not the compression after all. The match in your
> > response body suggests binary, but not quite.
> > What is this actually? Request and Response headers would be welcome.
> > 
> > Ahoj,
> > 
> > Christian
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
> Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> http://www.modsecurity.org/projects/commercial/rules/
> http://www.modsecurity.org/projects/commercial/support/
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
> Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> http://www.modsecurity.org/projects/commercial/rules/
> http://www.modsecurity.org/projects/commercial/support/