0

I have a Java-Servlet based web application using spring saml and Modsecurity.

For one of the GET requests (URL - /saml/login), the response is a HTML page returned as text/html(I can read the html file in browser network tools) along with Content-Length header. This is when Modsecurity is disabled.

When I enable ModSecurity in the app, the same response is returned with header Transfer-encoding: chunked. This time the html response is encoded due to chunking. Eg <html is displayed as 10<60h104t116m109l108. I am not sure if the browser is supposed to be decoding this but this is breaking the flow of my application. As the response is shown on the browser in the encoded form.

I have tried commenting out rules in ModSecurity to find out which is causing the response to be chunked with no success. Since another developer implemented ModSecurity, at this point I am not sure how solve this by making changes to ModSecurity.

Thus I want to try to decode the response in Java code or on the browser. If the Html file is rendered normally, the subsequent requests will start working.

EDIT 1:

ModsecurityFilter configuration in the web.xml:

<filter>
        <filter-name>ModSecurityFilter</filter-name>
        <filter-class>org.modsecurity.ModSecurityFilter</filter-class>
        <init-param>
            <param-name>conf</param-name>
            <param-value>/opt/ModSecurityFilter/modsecurity.conf</param-value>
        </init-param>
        <init-param>
            <param-name>libxml2</param-name>
            <param-value>/usr/lib/x86_64-linux-gnu/libxml2.so.2</param-value>
        </init-param>
        <init-param>
            <param-name>libpcre</param-name>
            <param-value>/lib/x86_64-linux-gnu/libpcre.so.3</param-value>
        </init-param>
        <init-param>
            <param-name>libaprutil-1</param-name>
            <param-value>/usr/lib/x86_64-linux-gnu/libaprutil-1.so.0</param-value>
        </init-param>

        <init-param>
            <param-name>libapr-1</param-name>
            <param-value>/usr/lib/x86_64-linux-gnu/libapr-1.so.0</param-value>
        </init-param>

        <init-param>
            <param-name>libModSecurityJNI</param-name>
            <param-value>/opt/ModSecurityFilter/java/.libs/libModSecurityJNI.so</param-value>
        </init-param>
</filter>
<filter-mapping>
        <filter-name>ModSecurityFilter</filter-name>
        <url-pattern>/*</url-pattern>
</filter-mapping>
adarsh hegde
  • 1,353
  • 2
  • 21
  • 43
  • Never heard of this before. What web server are you using with ModSecurity (Apache? Nginx? IIS?), what platform (Linux? Windows?) and what version of ModSecurity? – Barry Pollard Jul 12 '17 at 08:35
  • I am using a apache tomcat v8 web server and an Ubuntu OS with ModSecurity version 2.7. – adarsh hegde Jul 12 '17 at 09:46
  • ModSecurity is not supported on Tomcat so are you running Apache in front of it? Can you try setting "SecDisableBackendCompression On" and see if that helps? – Barry Pollard Jul 12 '17 at 09:51
  • BazzaDP - I tried this but it didn't work in my case. – adarsh hegde Jul 12 '17 at 12:05
  • In my case there is only a apache tomcat server. I am not sure how Modsecurity has been built on this server. I am editing my answer with the ModSecurityFilter configuration in the web.xml. – adarsh hegde Jul 12 '17 at 12:12

1 Answers1

0

It appears you are sending back the ASCII codes as well as the text. Never seen that before and don't know why ModSecurity would do this. Transfer-Encoding: chunked is a standard HTTP response and both the server and client should be able to handle this and it shouldn't change the format of what is sent back.

Looks you are using a little used and older ModSecurity for Java as detailed here: https://www.trustwave.com/Resources/SpiderLabs-Blog/ModSecurity-for-Java---BETA-Testers-Needed/

I wasn't aware this existed and it hasn't been maintained in over 4 years so not sure how stable it is to be honest.

You could try adding a comment on above page, or asking for help on the ModSecurity user mailing list: https://sourceforge.net/projects/mod-security/lists/mod-security-users

One other thing that might be worth trying would be turning off response body processing by changing this line in your modsecurity.conf file:

SecResponseBodyAccess On

to this:

SecResponseBodyAccess Off

And then restarting Tomcat. This should pass responses back without ModSecurity processing them.

Response bodies are normally used for information leakage so, for example, a verbose debug log, with potential details of the inner working of the application are not sent back to the client. However, while this is useful, mostly a WAF like ModSecurity is to protect against inbound attacks. Processing response bodies also has performance impacts as requests are normally small, and therefore easier to process, while responses can be quite large (full HTML pages). Therefore I do not think you lose too much by turning this off and may even gain on the protection.

Barry Pollard
  • 40,655
  • 7
  • 76
  • 92
  • BazzaDP : Thank you for the detailed response. I appreciate it! I had tried this option(SecResponseBodyAccess Off) but it didn't work for me. Is there a way to turn off modsecurity for a a particular URL request or a particular response header? If yes, can you please point out the required configuration. – adarsh hegde Jul 12 '17 at 13:19
  • Where did you get thar option() syntax from? Don't recognise that. See here on how to write rules to turn off ModSecurity: https://stackoverflow.com/questions/42829492/how-to-add-mod-security-exception/42832490#42832490 – Barry Pollard Jul 12 '17 at 14:58
  • Even after turning of the rules at a global level I am not able to fix this problem. I think the issue is due to the ModSecurity Filter or due to one of the libraries in the ModSecurity dependency. – adarsh hegde Jul 13 '17 at 10:21
  • To be honest I'd just turn it off. Stick Apache in front with up to date ModSecurity in it if you want it. Appreciate that's more hassle for you to set up but there are advantages to having a web server in front of app server. – Barry Pollard Jul 13 '17 at 10:49