ESAPI 2.5.1.0 is reported as vulnerable to CVE-2023-24998

[mbektchiev]

Our static code scanner reports that the latest version of ESAPI (2.5.1.0) depends on the Apache Commons FileUpload library version 1.4 which is vulnerable to CVE-2023-24998

Are you planning on releasing a new version that uses version 1.5 and configures it so that the vulnerability is mitigated by default:

Apache Commons FileUpload before 1.5 does not limit the number of request parts to be processed resulting in the possibility of an attacker triggering a DoS with a malicious upload or series of uploads. Note that, like all of the file upload limits, the new configuration option (FileUploadBase#setFileCountMax) is not enabled by default and must be explicitly configured.

If not, can you recommend a way to address this vulnerability report?

[mbektchiev]

Closing - this is not the correct repository for version 2.x

[kwwall]

Also, @mbektchiev - that vulnerability has already been addressed in the 'develop' branch for ESAPI 2.x (under esaph-java-legacy repo).

The workaround is simple. Just exclude in an section of your project's pom.xml and then add an explicit dependency for the patched 1.5 version of Apache Commons FileUpload.

See the Workaround section of Security Bulletin 5 for an example of how to do this for commons-io.

[mbektchiev]

@kwwall Thanks for reaching out to me. My question would be: is just referencing 1.5 instead of 1.4 enough in your view? The reason I'm concerned is this statement in the CVE description: the new configuration option (FileUploadBase#setFileCountMax) is not enabled by default

[kwwall]

@mbektchiev - To answer your question is a bit complicated.

I guess that depends on whether you are actually using any of ESAPI's HTTPUtilities.getFileUploads() methods or ESAPIWebApplicationFirewallFilter or not. If you are not using any of those, you should be okay even with Apache Commons FileUpload 1.4 because that are the only (intended to be public) classes / methods that use it. So, in that case, upgrading to 1.5 should make an SCA tool that has a clue to stop complaining.

If you are using one of those methods, it is a bit more complicated. ESAPI sets a maximum bytes limitation, but not a maximum file count. But we use org.apache.commons.fileupload.servlet.ServletFileUpload to handle the uploads and it has not changed at all between release 1.4 and 1.5. And while ServletFileUpload uses FileUploadBase, it only uses it to call FileUploadBaseFileUploadBase.isMultipartContent() as part of the implementation for ServletFileUpload.isMultipartContent() (which we do call, but is not involved in the DoS attack; it just checks whether multipart/mixed encoding is being used or not).

That said, because we are not using FileUploadBase and ServletFileUpload doesn't have a way to limit the maximum number of files being uploaded, the CVE's note about needing to call to FileUploadBase.setFileCountMax() is somewhat pointless in this context.

Since file uploads in Apache Commons Upload is per session, we deemed it more critical to put an upper limit on the number of bytes uploaded rather the number of files. One may be able to make the case (if you can show me an existing threat model with it before CVE-2023-24998 was announced) that this is an edge that ESAPI ought to handle. If you think that, then write up a GitHub issue (but for the esapi-java-legacy repo, not this one) and we will consider it. (Or better, submit an issue and a PR that addresses it!)

[mbektchiev]

@kwwall Thanks for the thorough explanation! 🙏

We are using neither HTTPUtilities.getFileUploads(), nor ESAPIWebApplicationFirewallFilter , so we'll be fine by just updating commons-fileupload to silence the scanner.

[kwwall]

Update: ESAPI 2.5.1.0 and earlier is impacted by this CVE. A more detailed explanation is available on the GitHub Discussions board at ESAPI/esapi-java-legacy#782. Please see that for details.