Configuration directive SecUploadFileLimit is exclusive

[regazzoj]

Describe the bug

The directive SecUploadFileLimit is exclusive, so when we expect to have a maximum of 10 files, we need to put 11 as value.

To Reproduce

Steps to reproduce the behavior:

Just set to directive SecUploadFileLimit to a value 10. Try to upload 10 files and modsecurity will block the request because the limit is reached.

Expected behavior

If the limit is set to 10, I expect to be able to upload 10 files.

Server (please complete the following information):

• ModSecurity version (and connector): ModSecurity v3.0.6
• WebServer: nginx-1.20.2
• OS (and distro): Linux, Ubuntu with Docker

Rule Set (please complete the following information):

• Running any public or commercial rule set? Public

It might be an expected behavior, but I can't find anywhere that this directive is exclusive.

[martinhsv]

Hello @regazzoj ,

I don't believe this is expected behaviour. The ordinary English meaning of 'limit' is an inclusive boundary; i.e. only going beyond the stated number is what should trigger the changed state.

Also, ModSecurity v2 does treat it as you suggest (as an inclusive boundary) and it looks like the the v3 code was structured with an intent to follow the same logic.

[regazzoj]

Hello @martinhsv ,

Thanks for your answer.

Okay, so it should work the way I think, but it doesn't. I try again with a limit set to 5. So I checked that I am using the good directive and that it is used. And I reproduced the same behavior, I can't upload 5 files or more, but 4 is fine...

Well, obviously it is easily fix by just adding one to the value, so not a real problem.

[martinhsv]

I suspect most users setting this value are not selecting a value that is particularly precisely chosen. They're just setting a high-ish limit (20? 30?) that is a fair bit higher than any expected (for their deployment), legitimate HTTP request would contain, but that still provides some protection against abuse. That would be consistent with why this boundary-issue has never been noticed before.

Of course, just because it's not common, does not mean there are no deployments where a smaller, more precise number is preferred.

I'll leave this open, since it's worth addressing. But, as you point out, since there is a straightforward way to adjust one's configuration, it probably won't rank as high-priority for the immediate future.

Thanks for pointing this out.