javaservletscheckmarxesapi

Error:Processing Request..Failed :java.lang.NoClassDefFoundError: org.apache.commons.fileupload.FileItemFactory


i am facing trust boundary violation issue in my application for this using below method but applciation is not working!

public static  String[] getValidInput(String[] input) {
        Log4j.log("info", "Enter Into getValidInput() ESAPI"+Arrays.toString(input));
        if(input==null) {
            return input;
            }
        List<String> res = new ArrayList<>();
        try {
        for(String str :input) {
            String output= ESAPI.validator().getValidInput("Validationofinput", str, "SafeString", 1000, false);
            res.add(output);
        }
        return res.toArray(new String[0]);
}
public String getRqst(HttpServletRequest request, String param) {
    String[] reqs = Validate.getValidInput(request.getParameterValues(param)); -> here i amgetting trust boundary violation in session variables for this issue i am using ESAPI

SafeString : ^[.\p{Alnum}\p{Space}_-]{0,1024}$

added two below jars to application not working commons-fileupload-1.4, commons-io-2.4


Solution

  • The default implementation class for ESAPI's Validator interface is DefaultValidator. That in turn eventually pulls in the DefaultHTTPUtilities class which references the Apache Commons FileUpload.

    However, without additional information (e.g., details of the dependencies in your pom.xml or build.gradle, etc.), I can't help very much beyond that aside from describing what could cause this. If you want assistance, you will need to supply us with those details. I'd suggest by creating a toy program that uses Apache Commons FileUpload 1.4. Will it compile? Will it run?

    Unless you (in your application build file, e.g., pom.xml, build.gradle, etc.) are doing something to exclude Apache Commons FileUpload or your company is blocking Maven Central (many do), it should work. But many companies block Maven Central and they require you to pulling dependencies from something like a local JFrog Artifactory instance. If that is the case, it is possible that FileUpload 1.4 is not present there either. The 1.4 version could be getting blocked because there is a known unpatched vulnerability in FileUpload 1.4 (specifically, CVE-2023-24998; fixed [sort of] in 1.5). So the 1.4 version could be blocked by an SCA "firewall". [Note: If you use ESAPI 2.5.2.0, it will automatically use Apache Commons FileUpload 1.5 unless you did something to change it.]

    Anyhow, I need more details before I can help any further.