Body Inspection for PUT Failing

[guytp]

First attempt with ModSec / nginx so I apologise if this is my error. Seen references to this in 2.x but not 3.x.

I have ModSec 3.0 (v3/master) with nginx connection (master) and nginx 1.14.0 running rulset (v3.0/master).

If I have requests with a body using the PUT verb it appears that the body is not inspected and an error is generated. These requests with POST work fine. All PUT request seem affected.

The "-I" component of the log is empty and ""Failed to parse request body" errors are generated. Based on the Content-Length, the response from the server and the fact I've tested these requests manually suggests that the data is valid and being received by nginx/passed through - just that modsec seems to not notice it.

Any suggestions?

[09/Sep/2018:22:41:35 +0000] 153653289534.109623 162.158.106.106 40086 162.158.106.106 443
---zwex8Mov---B--
PUT /licensing/1/[redacted]/activations/[redacted] HTTP/1.1
Content-Type: application/json; charset=utf-8
CF-Visitor: {"scheme":"https"}
Content-Length: 72
X-Forwarded-For: 67.41.254.105
CF-IPCountry: US
Host: [redacted]
Accept-Encoding: gzip
X-Forwarded-Proto: https
User-Agent: cpprestsdk/2.8.0
Connection: Keep-Alive
CF-RAY: 457d297dde162a8b-SEA
Authorization: BEARER [redacted]
CF-Connecting-IP: 67.41.254.105

---zwex8Mov---D--

---zwex8Mov---F--
HTTP/1.1 200
Server: nginx/1.14.0
Date: Sun, 09 Sep 2018 22:41:36 GMT
Content-Length: 4
Content-Type: application/json; charset=utf-8
Connection: keep-alive
X-Frame-Options: DENY

---zwex8Mov---H--
ModSecurity: Warning. Matched "Operator `Eq' with parameter `0' against variable `REQBODY_ERROR' (Value: `1' ) [file "/etc/nginx/modsec/modsecurity.conf"] [line "44"] [id "200002"] [rev ""] [msg "Failed to parse request body."] [data "JSON parsing error: lexical error: invalid char in json text.\x0a"] [severity "2"$
ModSecurity: Warning. Matched "Operator `Eq' with parameter `0' against variable `REQBODY_ERROR' (Value: `1' ) [file "/etc/nginx/modsec/rules/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf"] [line "118"] [id "920130"] [rev "1"] [msg "Failed to parse request body."] [data "JSON parsing error: lexical error: invalid cha$
ModSecurity: Warning. Matched "Operator `Ge' with parameter `5' against variable `TX:ANOMALY_SCORE' (Value: `5' ) [file "/etc/nginx/modsec/rules/rules/REQUEST-949-BLOCKING-EVALUATION.conf"] [line "36"] [id "949110"] [rev ""] [msg "Inbound Anomaly Score Exceeded (Total Score: 5)"] [data ""] [severity "2"] [ver ""] [$
ModSecurity: Warning. Matched "Operator `Ge' with parameter `5' against variable `TX:INBOUND_ANOMALY_SCORE' (Value: `5' ) [file "/etc/nginx/modsec/rules/rules/RESPONSE-980-CORRELATION.conf"] [line "61"] [id "980130"] [rev ""] [msg "Inbound Anomaly Score Exceeded (Total Inbound Score: 5 - SQLI=0,XSS=0,RFI=0,LFI=0,RC$

---zwex8Mov---I--

---zwex8Mov---J--

---zwex8Mov---Z--

built by gcc 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.10)
built with OpenSSL 1.0.2g  1 Mar 2016
TLS SNI support enabled
configure arguments: --prefix=/usr/share/nginx --conf-path=/etc/nginx/nginx.conf --http-log-path=/var/log/nginx/access.log --error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --with-debug --with-pcre-jit --with-http_ssl_module --with-http_stub_status_module --with-http_realip_module --with-http_auth_request_module --with-http_addition_module --with-http_dav_module --with-http_geoip_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_image_filter_module --with-http_v2_module --with-http_sub_module --with-http_xslt_module --with-stream --with-stream_ssl_module --with-mail --with-mail_ssl_module --with-threads --add-module=/usr/src/ModSecurity-nginx --with-compat```

[victorhora]

Hi @guytp

I think your problem is here:

ModSecurity: Warning. Matched "Operator `Eq' with parameter `0' against variable `REQBODY_ERROR' (Value: `1' ) [file "/etc/nginx/modsec/modsecurity.conf"] [line "44"] [id "200002"] [rev ""] [msg "Failed to parse request body."] [data "JSON parsing error: lexical error: invalid char in json text.\x0a"]

I think this might be related with requests containing empty JSON data. Please go over issues owasp-modsecurity/ModSecurity#1392 and maybe owasp-modsecurity/ModSecurity#1879 to understand if it's related.

Also, can you post the content of the body of the request so we can try to reproduce the issue you're facing? You may need to add section "C" of SecAuditLogParts to your configuration which might explain why you're not seeing the POST data on your logs.

You may also want to check that SecRequestBodyAccess is "On" to ensure that the body is actually being inspected in the first place.

[guytp]

This happens with a number of body-types. One of which is an authentication endpoint with the JSON content:

{"Username":"xxx", "Password":"yyy"}

There are some others but that is the simplest request type generating this. Confirmed these requests are not empty. These are all for ProxyPass directives. If in DetectionOnly mode the actual server that handles the API calls gets the full request with JSON and returns a valid response. This also happens with requests I manually fire off to the endpoint.

SecRequestBodyAccess is definitely on - hence no problems with POST requests.

Adding "C" to SecAuditLogParts makes no difference - have also tested this.

No special characters from #1879 nor is the body empty from #1392.

I can provide a full set of log files if required and additional logs if required. Let me know if there's anything else that can help with this.

[victorhora]

Hummm weird :/

Please share your modsecurity.conf, nginx.conf, audit_logs and debug_logs in a Gist for further investigation. You don't need to share all of the confs, just minimal reproducible configuration files that can help us on try reproducing the issue.

Also, please share the full POST and PUT request that triggers the issue.

Thanks.

[zimmerle]

Closing the issue as we have no feedback from the user.