ModSecurity strips POST data information from request in DetectionOnly mode

[rcbarnett-zz]

MODSEC-390: For a Dutch bank we purchased the commercial ruleset from TrustWave labs. In the process of setting-up the ModSecurity in combination with IIS we hit an issue which we cannot solve and basically renders the ModSecurity module unusable for our environment.

When enabling ModSecurity for the default virtual host, POST parameters are no longer passed to the JBoss application server via the mod_jk plugin.
We deployed on this virtual host the mod_jk ISAPI module which works as expected when ModSecurity is disabled.

After enabling ModSecurity (DetectionOnly mode), access to the the login-page via Java ServerFaces works fine (and access to all other dynamic content which does not require POST information to be sent) until we try to submit for instance the username.

The submitted username is received by IIS (confirmed this through our Web Debugging Proxy (Charles)), but the POST parameter data itself is empty when received by our application (confirmed by the log files produced by the application).

In the Windows EventLog Application log there are no ModSecurity errors, only warnings concerning rules have been hit.

We installed ModSecurity using the MSI installer on IIS.
Installation seems successful, we see the in Windows EventLogger the ModSecurity Information logs:

ModSecurity for IIS (STABLE)/2.7.3 (http://www.modsecurity.org/) configured.
ModSecurity: APR compiled version="1.4.6"; loaded version="1.4.6"
ModSecurity: PCRE compiled version="8.30 "; loaded version="8.30 2012-02-04"
ModSecurity: LUA compiled version="Lua 5.1"
ModSecurity: LIBXML compiled version="2.7.7"

Please advice,
All the best,
Robin Huiser

[rcbarnett-zz]

Original reporter: rhuiser

[rcbarnett-zz]

bpinto: This is a known issue. Looks like some modules other than ASP.NET have problem forward request body with ModSecurity.

Right now you cannot enable request body in this cases. Setting SecRequestBodyAccess Off will make it work

Thanks

Breno

[rcbarnett-zz]

rhuiser: Thank you Breno for your swift answer!

Do you know when or which release of ModSecurity this issue will be solved since switching off the option will no longer protect us from XSS or SQL injection (amongst others)?

[rcbarnett-zz]

bpinto: Hello Robin,

We are discussing it with Microsoft. This is an issue based on IIS arch. Right now we don't have an ETA for this issue. However we agree this should be fixed as soon as possible.

Turning off SecRequestBodyAccess means modsecurity will not protect attacks coming into request body. So basically modsecurity will inspect request headers. If SQL attacks are going into requests headers, modsecurity will still protect.

Thanks

Breno

[rcbarnett-zz]

rhuiser: Hi Breno,

We tried to work around the issue by splitting the virtual hosts in IIS; VHOST 1 with ModSecurity including Application Request Routing module of Microsoft to act as a reverse proxy by forwarding all (scanned) traffic to VHOST 2 which has ModJK deployed:

VHOST 1

ModSecurity
ARR 2.5 ----------------> VHOST 2
========
ModJK -------------------> JBOSS SERVER

Unfortunately, when switching "SecRequestBodyAccess" to "On", traffic is no longer forwarded (time out).

Another setup we tried is to remove ModJK from the equation and have ARR forwarding all traffic to JBoss directly:

VHOST 1

ModSecurity
ARR 2.5 ----------------> JBOSS SERVER

Unfortunately, when switching "SecRequestBodyAccess" to "On", POST body is empty again.

Could you confirm from the architecture issues you are facing with ModSecurity / IIS / SecRequestBodyAccess the ARR module is also not usable in the setups shown above or is this a different issue?

Thanks in advance,
Robin

[rcbarnett-zz]

bpinto: Hello Robin,

Yes. Looks like the issue we are already working on.

Thanks

Breno

[rcbarnett-zz]

ianw: I am seeing the exact same symptoms on CentOS 6.4 + nginx 1.5.1 + ModSecurity 2.7.4 - does the same architecture issue exist for the nginx port?

Thanks,
Ian

[rcbarnett-zz]

bpinto: Could you please describe in details your environment and nginx + modsecurity configuration ? I would like to try reproduce.

Also if you can send details about the POST you are trying to send.

Thanks

[rcbarnett-zz]

ianw: The environment is a CentOS 6.4 installation; nginx has the following -V output:

nginx version: nginx/1.5.1
built by gcc 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC)
TLS SNI support enabled
configure arguments: --with-debug --with-ipv6 --with-http_ssl_module --with-http_spdy_module --with-http_realip_module --with-http_stub_status_module --with-pcre=/home/build/pcre-8.33 --with-pcre-jit --with-openssl=/home/build/openssl-1.0.1e --add-module=/home/build/modsecurity-apache_2.7.4/nginx/modsecurity

ModSecurity is built from the 2.7.4 release tarball, with the following options:
./configure --enable-standalone-module --enable-pcre-jit --with-pcre=../pcre-8.33

I can reproduce the problem with the modsecurity.conf-recommended from the 2.7.4 tarball and the Core Rules 2.27.

Any POST request can cause the issue. Here is a simple form that will trigger it, when combined with the below configuration:

First name:

I can reproduce with the following abbreviated configuration, which sends all requests upstream to the requestb.in service:

upstream requestbin {
server requestb.in;
}

server {
listen 80 default_server;
server_name testserver;

ModSecurityEnabled on;
ModSecurityConfig /etc/nginx/modsecurity.conf;

location / {
    root /var/www/html/;
}
location /requestbin/ {
    proxy_pass http://requestbin/12191nu1;
    proxy_set_header Host requestb.in;
}

}

[rcbarnett-zz]

ianw: Retested with ModSecurity 2.7.5 RC tarball; error is still present. Is there any other status update on this?

[rcbarnett-zz]

bpinto: Ian,

I didn't test with your module options. Just with default nginx modules + modsecurity and a similar configuration:

upstream backend {
    server 192.168.0.103:80;
}

server {
    listen       80;
    server_name  localhost;
    proxy_set_header Accept-Encoding " ";
    ModSecurityEnabled on;
    ModSecurityConfig modsecurity.conf;
    location / {
        root   html;
        index  index.html index.htm;
        proxy_pass http://backend;
        proxy_read_timeout 300;
    }

    location /backend/ {
        proxy_pass http://backend;
        proxy_read_timeout 300;
    }

Then submit a POST to 192.168.0.103/backend/index.html and all looks fine from my side. I will need more time to try reproduce your issue.
Do you see anything from my config i should change to reproduce ?

Thanks

Breno

[rcbarnett-zz]

ianw: I assume you mean submit the POST to localhost/backend/index.html? If submitted to 192.168.0.103/backend/index.html that bypasses the Nginx server entirely.

The critical setting is in my modsecurity.conf:
SecRequestBodyAccess On

If this is set to "Off" my installation works fine; with it "On" all POSTs are truncated during the forward to the backend server.

Thanks,
Ian

[rcbarnett-zz]

bpinto: Yes. Sorry for the typo. Sending it to localhost (nginx server)

SecRequestBodyAccess is also On from my side.

Could you attach your debug.log (level 9) with the malformed POST ?

Thanks

[rcbarnett-zz]

ianw: My apologies for taking so long to get back to this. I've attached a level 9 debug log from ModSecurity for the failed request and also an Nginx debug log for the same request.

[ifastnet]

I am also seeing this on nginx + mod_security , logins to common applications (eg wordpress) are broken, super easy to reproduce enable requestbody access, and then try logging into a default wordpress (this is nginx 1.4.1 and trunk mod_security ) .

[thaeli]

Any update on this? Did the file attachments transfer over, or do I need to reattach the debug logs?

[zimmerle]

Related to nginx and posts, there are two bugs that may affect the behavior of applications such Wordpress, they are: #154 and #142. The first one was about the inability to set more than one cookie in certain circumstances (applicable only to the nginx port). As reported in the bug it was fixed and available under the development tree. The second just happens with large POSTs and it was not fixed yet, more detail available at #142.

[seanym007]

Hi,

I'm wondering if this issue is still being looked at? I downloaded the latest version of Modsec 2.7.7, and installed on iis 8.0. I then setup an ARR proxy. The symptoms above is still happening, so post requests timeout, but all get requests work perfectly ok. Switching off the SecRequestBodyAccess means it now works, as described above, however as previously noted, I'm now concerned that I've switched off quite a major bit of functionality, and since this proxy I'm building will handle data for a payments solution, my worry is now that my proxy will not be as robust as it needs to be..

[code1955]

Hi,

We are suffering an issue related to POST inspection, although not same impact as those described above.
We are running modsecurity 2.7.x on apache 2.5.3
Backend application is running on Jetty 2.9.
The application presents a login form to the end user.
When filling in the login fields with crafted data, like sql strings, the call is accepted and sent to the backend application.
But adding sql strings in the URL, the call is blocked.
Here is our configuration of mod security

[seanym007]

if you put this line into modesc.conf:

SecStreamInBodyInspection On

it appears to resolve the issue. Putting this line in my config solved the issues I was having, although I'm unsure if modsec has now been compromised in some way..

[code1955]

indeed something that I missed.
Thank you

[seanym007]

no problem.. hope this solves your issue..

[code1955]

It doesn't :-(

[code1955]

What do you mean with "although I'm unsure if modsec has now been compromised in some way."?

[seanym007]

well I just mean that this rule fixes my issue, however I don't have a full understanding of how or why.. It could be that its turning something off.

Previous to that, I turned SecRequestBodyAccess Off as suggested above, however as this does compromise modsec I looked for an alternative fix hence the suggestion I made above.

[code1955]

Thanks.
However it's not working for me.

[code1955]

well, I'm going to open a new case.
I hope there will be replies

[Zetanova]

SecStreamInBodyInspection On worked on IIS7.5 ARR2.5

[marcher233]

We are using Microsoft Dynamics NAV 2016 Web Client but POST parameters won't forward correctly when SecRequestBodyAccess is set as On.

Adding SecStreamInBodyInspection On to config file works on IIS8.5.

[pleothaud]

SecStreamInBodyInspection On to config file works on IIS8.5, Server 201212 R2 (in Azure)

Also I checked that POSTed variables were still checked : they are J

[victorhora]

SecStreamInBodyInspection should be turned on for IIS.

As for Nginx, support for this module in ModSecurity 2.9.x branch is deprecated. This shouldn't be a concern with libModSecurity.

Thanks!