ESAPI 2.5.1.0 is reported as vulnerable to CVE-2023-24998 about esapi-java HOT 6 CLOSED

@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.

from esapi-java.

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

from esapi-java.

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.

from esapi-java.

@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

from esapi-java.

@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!)

from esapi-java.

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.

from esapi-java.