Skip to content

Does not pass through POST data to back-end when SecRequestBodyAccess is set to On #630

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
dimyse opened this issue Dec 20, 2013 · 11 comments
Assignees

Comments

@dimyse
Copy link

dimyse commented Dec 20, 2013

Modsecurity(2.7.7) nginx 1.5.X does not pass through POST data to back-end when SecRequestBodyAccess is set to On

@omadjoudj
Copy link
Contributor

I was not able to reproduce this issue with nginx 1.4.4 modsecurity 2.7.7 and CRS with different VMs for frontend and backend , could you provide more details about your setup.

To make sure that I've understood your issue correctly, your nginx is not filtering POST requests sent to the backend servers OR backend's responses are not filtered by nginx which needs SecResponseBodyAccess to be On (didn't test the later)

@dimyse
Copy link
Author

dimyse commented Dec 21, 2013

If the option "SecRequestBodyAccess On" all large POST requests are blocked.
This occurs when using the admin panel of the CMS.
--nginx.conf--1.5.8--
worker_processes 5;
events {
worker_connections 65536;
use epoll;}
http {
include mime.types;
default_type application/octet-stream;
sendfile on;
keepalive_timeou 5;
gzip off;
server_tokens off;
reset_timedout_connection on;
ModSecurityEnabled on;
ModSecurityConfig modsecurity.conf;
server {
listen 80;
server_name localhost;
server_name_in_redirect off;
resolver 127.0.0.1 valid=300s;
}
location / {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $host;
proxy_redirect off;
proxy_pass http://$host:80;
} }}
--nginx.conf--1.5.8--

--modsecurity.conf--2.7.7--
SecRuleEngine on
SecAuditEngine RelevantOnly
SecAuditLogParts ABCEFHZ
SecAuditLog /usr/local/nginx/logs/modsec_audit.log
SecRequestBodyAccess On
SecRequestBodyLimit 1310720
SecRequestBodyNoFilesLimit 1310720
SecRequestBodyInMemoryLimit 31310720
SecRequestBodyLimitAction ProcessPartial
SecResponseBodyAccess Off
--modsecurity.conf--2.7.7--

OR

Installed Packages from epel-nginx-mod_security.repo
Name : nginx
Arch : x86_64
Epoch : 1
Version : 1.4.4
Release : 1.modsec_2.7.7.el6

@zimmerle
Copy link
Contributor

Hi Guys,

There was a similar issue reported on #148 which was intended to by fixed by the merge request #148. Recently @ahuango noticed that the merge request was not really solving the issue and there was another merge request at #614. This second merge request was merge into our branch master and it is schedule to be delivered by the next release. Can you test the branch "master" to check if you guys can reproduce this issue?

Thanks,
F.

@ghost ghost assigned zimmerle Dec 21, 2013
@dimyse
Copy link
Author

dimyse commented Dec 21, 2013

Tried on version "master" the same result. Large post requests getting 408 (Request Timeout) from back-end/

@zimmerle
Copy link
Contributor

@dimyse This is may a duplicate of #142. Not confirmed yet.

@zimmerle
Copy link
Contributor

zimmerle commented May 6, 2014

Hi @dimyse, there is a development branch of the nginx version where this issue should be fixed, can you test it?

it is available at:
https://github.com/SpiderLabs/ModSecurity/tree/nginx_refactoring

@kyprizel
Copy link

I've tested new branch - the problem is not fixed.

if we use ngx_http_modsecurity_save_request_body / ngx_http_modsecurity_load_request_body
u->conf->upstrea will be set to NULL in ngx_http_proxy_handler

@zimmerle
Copy link
Contributor

Hi @kyprizel, just to confirm, you have tested nginx branch: "nginx_refactoring" with a configuration similar of what we have on the comment: #630 (comment)
and your application did not received the content of the POST request, right? there is any crash associated? do you mind to share the logs?

Thanks.
F.

@kyprizel
Copy link

2014/05/25 17:14:03 [debug] 19370#0: *14 ModSec: Catching a new access phase handler. Count: 1
2014/05/25 17:14:03 [debug] 19370#0: *14 ModSec: Recovering ctx: 0000000000000000
2014/05/25 17:14:03 [debug] 19370#0: *14 add cleanup: 0000000000CA86F0
2014/05/25 17:14:03 [debug] 19370#0: *14 add cleanup: 0000000000CA8800
2014/05/25 17:14:03 [debug] 19370#0: *14 ModSec: ctx is now: 0000000000CA86C8 / count: 1
2014/05/25 17:14:03 [debug] 19370#0: *14 ModSec: asking for the request body, if any.
2014/05/25 17:14:03 [debug] 19370#0: *14 http client request body preread 280
2014/05/25 17:14:03 [debug] 19370#0: *14 http request body content length filter
2014/05/25 17:14:03 [debug] 19370#0: *14 http body new buf t:1 f:0 0000000000CA8DB1, pos 0000000000CA8DB1, size: 280 file: 0, size: 0
2014/05/25 17:14:03 [debug] 19370#0: *14 ModSec: reading request body...
2014/05/25 17:14:03 [debug] 19370#0: *14 ModSec: request is ready to be processed.
2014/05/25 17:14:03 [debug] 19370#0: *14 ModSec: starting to process the request...
2014/05/25 17:14:03 [debug] 19370#0: *14 ModSecurity: load headers in: "Content-Length: 280"
...
2014/05/25 17:14:03 [debug] 19370#0: *14 ModSecurity: load headers in done
2014/05/25 17:14:03 [debug] 19370#0: *14 ModSecurity: status -1
2014/05/25 17:14:03 [debug] 19370#0: *14 ModSec: request body will be processed...
2014/05/25 17:14:03 [debug] 19370#0: *14 ModSec: loading request body...
2014/05/25 17:14:03 [debug] 19370#0: *14 ModSec: loading request body.
2014/05/25 17:14:03 [debug] 19370#0: *14 ModSec: processing request body...
2014/05/25 17:14:03 [debug] 19370#0: *14 ModSecurity: status -1
2014/05/25 17:14:03 [debug] 19370#0: *14 ModSecurity: save headers in: "Content-Length: 280"
...
2014/05/25 17:14:03 [debug] 19370#0: *14 ModSecurity: save headers in done
2014/05/25 17:14:03 [debug] 19370#0: *14 ModSec: returning NGX_DECLINED.
2014/05/25 17:14:03 [debug] 19370#0: *14 generic phase: 6
2014/05/25 17:14:03 [debug] 19370#0: *14 generic phase: 7
2014/05/25 17:14:03 [debug] 19370#0: *14 generic phase: 8
2014/05/25 17:14:03 [debug] 19370#0: *14 access phase: 9
2014/05/25 17:14:03 [debug] 19370#0: *14 access phase: 10
2014/05/25 17:14:03 [debug] 19370#0: *14 access phase: 11
2014/05/25 17:14:03 [debug] 19370#0: *14 post access phase: 12

now upstream config in ngx_http_proxy_module is zero.
2014/05/25 17:14:03 [alert] 19370#0: *14 no upstream configuration, client: XXX.XXX.XXX.XXX, server: myserver.com, request: "POST /"
2014/05/25 17:14:03 [debug] 19370#0: *14 finalize http upstream request: 500
2014/05/25 17:14:03 [debug] 19370#0: *14 finalize http proxy request

nginx config is the same as in the first message.
ModSecurity config is

SecRuleEngine DetectionOnly
SecRequestBodyAccess On
SecResponseBodyAccess Off
SecDefaultAction "phase:2,log,deny,status:500"
SecRequestBodyLimit 13107200
SecRequestBodyNoFilesLimit 131072
SecRequestBodyInMemoryLimit 131072
SecRequestBodyLimitAction Reject
SecResponseBodyAccess Off

SecAuditLogType Concurrent # tried Serial also

SecAuditEngine RelevantOnly
SecAuditLogRelevantStatus "^(?:5|4(?!04))"
SecAuditLogParts ABIJDEFHZ

As I can see - the problem is in nginx modules body reading process.

@dimyse
Copy link
Author

dimyse commented Jul 2, 2014

We tested, the issue is resolved.
Thanks for your support.


zimmerle commented on 6 May
Hi @dimyse, there is a development branch of the nginx version where this issue should be fixed, can you test it?
it is available at:
https://github.com/SpiderLabs/ModSecurity/tree/nginx_refactoring


@smashpunk
Copy link

@kyprizel can you share if your problem been resolved?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants