Description
Describe the bug
When SecRequestBodyNoFilesLimit is set to a very high value, all requests get incorrectly blocked as being too large. This does not happen on Apache.
Logs and dumps
---zcw5rmqN---A--
[31/Mar/2025:16:45:39 +1100] 174339993925.897781 ::1 52958 ::1 8080
---zcw5rmqN---B--
POST / HTTP/1.1
Host: localhost:8080
User-Agent: curl/8.5.0
Accept: */*
Content-Length: 10
Content-Type: application/x-www-form-urlencoded
---zcw5rmqN---C--
test=hello
---zcw5rmqN---D--
---zcw5rmqN---E--
<html>\x0d\x0a<head><title>400 Bad Request</title></head>\x0d\x0a<body>\x0d\x0a<center><h1>400 Bad Request</h1></center>\x0d\x0a<hr><center>nginx/1.24.0 (Ubuntu)</center>\x0d\x0a</body>\x0d\x0a</html>\x0d\x0a
---zcw5rmqN---F--
HTTP/1.1 400
Server: nginx/1.24.0 (Ubuntu)
Date: Mon, 31 Mar 2025 05:45:39 GMT
Content-Length: 166
Content-Type: text/html
Connection: close
---zcw5rmqN---H--
ModSecurity: Access denied with code 400 (phase 2). Matched "Operator `Eq' with parameter `0' against variable `REQBODY_ERROR' (Value: `1' ) [file "/etc/modsecurity/modsecurity.conf"] [line "69"] [id "200002"] [rev ""] [msg "Failed to parse request body."] [data "Request body excluding files is bigger than the maximum expected."] [severity "2"] [ver ""] [maturity "0"] [accuracy "0"] [hostname "::1"] [uri "/"] [unique_id "174339993925.897781"] [ref "v0,1"]
According to the debug log, it looks like an integer overflow is happening? I've attached the full debug log just in case.
[174339993925.897781] [/] [9] Appending request body: 10 bytes. Limit set to: 13107200.000000
[174339993925.897781] [/] [4] Starting phase REQUEST_BODY. (SecRules 2)
[174339993925.897781] [/] [5] Request body excluding files is bigger than the maximum expected. Limit: -2147483648.000000
[174339993925.897781] [/] [9] This phase consists of 306 rule(s).
[174339993925.897781] [/] [4] (Rule: 200002) Executing operator "Eq" with param "0" against REQBODY_ERROR.
[174339993925.897781] [/] [9] Target value: "1" (Variable: REQBODY_ERROR)
[174339993925.897781] [/] [9] Matched vars updated.
[174339993925.897781] [/] [4] Rule returned 1.
[174339993925.897781] [/] [9] Running action: log
[174339993925.897781] [/] [9] Saving transaction to logs
[174339993925.897781] [/] [9] Running action: auditlog
[174339993925.897781] [/] [9] Saving transaction to logs
[174339993925.897781] [/] [9] This rule severity is: 2 current transaction is: 255
[174339993925.897781] [/] [9] Saving msg: Failed to parse request body.
[174339993925.897781] [/] [9] Running action: log
[174339993925.897781] [/] [9] Saving transaction to logs
[174339993925.897781] [/] [9] Running action: status
[174339993925.897781] [/] [4] Running (disruptive) action: deny.
[174339993925.897781] [/] [8] Running action deny
To Reproduce
Steps to reproduce the behavior:
- Set
SecRequestBodyNoFilesLimitto10737418240 curl -d "test=hello" localhost.
Request will be incorrectly blocked as being too large:
2025/03/31 16:45:39 [error] 2047#2047: *1 [client ::1] ModSecurity: Access denied with code 400 (phase 2). Matched "Operator `Eq' with parameter `0' against variable `REQBODY_ERROR' (Value: `1' ) [file "/etc/modsecurity/modsecurity.conf"] [line "69"] [id "200002"] [rev ""] [msg "Failed to parse request body."] [data "Request body excluding files is bigger than the maximum expected."] [severity "2"] [ver ""] [maturity "0"] [accuracy "0"] [hostname "::1"] [uri "/"] [unique_id "174339993925.897781"] [ref "v0,1"], client: ::1, server: _, request: "POST / HTTP/1.1", host: "localhost:8080"
This behavior does not happen on Apache.
Expected behavior
Request should not be blocked since I am below the limit.
Server (please complete the following information):
- ModSecurity version (and connector): ModSecurity v3.0.14 with nginx-connector v1.0.3
- WebServer: NGINX 1.24.0
- OS (and distro): Ubuntu 24.04
Rule Set (please complete the following information):
N/A
Additional context
Metadata
Metadata
Assignees
Type
Projects
Milestone
Relationships
Development
Participants
Activity
airween commentedon Mar 31, 2025
@EsadCetiner thanks for reporting this.
After a quick review, this issue is very similar to #3352. There this directive is not set, and it seems like the result is the same.
I have to check these together. Thanks again.