You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
SecRequestBodyNoFilesLimit is a configuration item available in ModSecurity v2 that supplements the older config item SecRequestBodyLimit. The difference between the two being that the former excludes file upload content within multipart requests from its byte count.
This directive has never been supported in libmodsecurity (aka ModSecurity v3).
A pull request (#2265 ) had been previously submitted to implement this support but was closed at the time. This issue is being created to support renewed consideration of this functionality, with a potential target of the next maintenance release.
Any libmodsecurity solution should not necessarily attempt to exactly emulate v2 behaviour. See the Additional Notes lower down for two specifics.
Minimum functional requirements to satisfy this issue should include:
when any of the three parsers XMLRequestBody, JSONRequestBody, WWWFormUrlEncoded are engaged, the entire request body size should be compared against the new config value if one has been specified
when the MultiPartRequestBody parser has been engaged, the byte count for the comparison must exclude request body bytes that represent file content.
When SecRuleEngine On is in force, the test should happen before any of the three parsers in (1) above is called. Body processing should exit immediately if the limit is exceeded. This timing is to provide benefit from any performance issues related to the parsing itself.
For MultiPartRequestBody parser cases, the test cannot occur before the parser has begun. In this case, when SecRuleEngine On is set, the test and exit may wait until after multipart processing is complete (i.e. the multipart parsing itself does not need to be interrupted ). However, the test and possible exit should occur no later than immediately after the parsing has completed (i.e. no phase:2 rules should run in this case)
Additional Notes:
A) If none of the four parsers listed in (1) and (2) above have been engaged, then the new limit will not be tested. This is a slight difference from v2, where the size of the REQUEST_BODY variable may be subject to the limit. For now, at least, it is likely undesirable to do the same in v3 since the conditions where REQUEST_BODY has been populated are broader. Failure to omit this check could result in undesirable false positives (e.g. a simple PUT request of a file where the Content-Type is something that did not engage one of ModSecurity's parsers)
B) Unspecified above is what should happen if SecRequestBodyLimitAction ProcessPartial has been configured. In v2 SecRequestBodyNoFilesLimit does not properly respect ProcessPartial. The v3 implementation may choose to treat such a ProcessPartial in combination with a breach of the new limit the same as SecRequestBodyLimitAction Reject. Other alternatives are possible such as modified Reject (allow parsing to proceed but treat as reject immediately afterwards -- this is closer to what v2 does)
The text was updated successfully, but these errors were encountered:
SecRequestBodyNoFilesLimit is a configuration item available in ModSecurity v2 that supplements the older config item SecRequestBodyLimit. The difference between the two being that the former excludes file upload content within multipart requests from its byte count.
This directive has never been supported in libmodsecurity (aka ModSecurity v3).
A pull request (#2265 ) had been previously submitted to implement this support but was closed at the time. This issue is being created to support renewed consideration of this functionality, with a potential target of the next maintenance release.
Any libmodsecurity solution should not necessarily attempt to exactly emulate v2 behaviour. See the Additional Notes lower down for two specifics.
Minimum functional requirements to satisfy this issue should include:
SecRuleEngine On
is in force, the test should happen before any of the three parsers in (1) above is called. Body processing should exit immediately if the limit is exceeded. This timing is to provide benefit from any performance issues related to the parsing itself.SecRuleEngine On
is set, the test and exit may wait until after multipart processing is complete (i.e. the multipart parsing itself does not need to be interrupted ). However, the test and possible exit should occur no later than immediately after the parsing has completed (i.e. no phase:2 rules should run in this case)Additional Notes:
A) If none of the four parsers listed in (1) and (2) above have been engaged, then the new limit will not be tested. This is a slight difference from v2, where the size of the REQUEST_BODY variable may be subject to the limit. For now, at least, it is likely undesirable to do the same in v3 since the conditions where REQUEST_BODY has been populated are broader. Failure to omit this check could result in undesirable false positives (e.g. a simple PUT request of a file where the Content-Type is something that did not engage one of ModSecurity's parsers)
B) Unspecified above is what should happen if
SecRequestBodyLimitAction ProcessPartial
has been configured. In v2SecRequestBodyNoFilesLimit
does not properly respect ProcessPartial. The v3 implementation may choose to treat such a ProcessPartial in combination with a breach of the new limit the same asSecRequestBodyLimitAction Reject
. Other alternatives are possible such as modified Reject (allow parsing to proceed but treat as reject immediately afterwards -- this is closer to what v2 does)The text was updated successfully, but these errors were encountered: