Skip to content
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

Support SecRequestBodyNoFilesLimit in libmodsecurity #2670

Closed
martinhsv opened this issue Jan 10, 2022 · 1 comment
Closed

Support SecRequestBodyNoFilesLimit in libmodsecurity #2670

martinhsv opened this issue Jan 10, 2022 · 1 comment
Labels
3.x Related to ModSecurity version 3.x

Comments

@martinhsv
Copy link
Contributor

martinhsv commented Jan 10, 2022

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:

  1. 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
  2. when the MultiPartRequestBody parser has been engaged, the byte count for the comparison must exclude request body bytes that represent file content.
  3. 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.
  4. 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)

@martinhsv martinhsv added the 3.x Related to ModSecurity version 3.x label Jan 10, 2022
@martinhsv
Copy link
Contributor Author

Merged via #2686

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
3.x Related to ModSecurity version 3.x
Projects
None yet
Development

No branches or pull requests

1 participant