sreeramadasugiri (Community Member) asked a question.

How to resolve External Control of File Name or Path (CWE ID
73), FTPClient class and ftpclientobject.listFiles(dynamicpath), dynamic path in java code

Hi Team,

My code in java,

FTPClient ftpClient = new FTPClient();

FTPFileInfo ftp = new FTPFileInfo(); -- variables declaration in class like port,hostname,uname,pwd,path etc....

--------------------------------

-----------------------------------

FTPFile[] files = ftpClient.listFiles(ftp.getFilePath());

// Here ftp.getFilePath() is we are getting dynamicpath in java code

if(files!=null)

{

for (FTPFile file : files) {

if (file.isFile()) {

--------------------

}

}

}.

 

I am getting vulnerabilities in the line ftpClient.listFiles(ftp.getFilePath()); (CWE ID 73 flaw issues), i searched multiple articles, but still i am not getting as i expected answer to solve my issue. Can you help me to resolve my flaw issue (CWE ID 73).


  • Hi @sreeramadasugiri (Community Member)​,

     

    Veracode Static Analysis reports CWE 73 ("External Control of File Name or Path", also called "Path Injection") when it can detect that data coming from outside the application, such as an HTTP request, a file, or even your database, is being used to access a file path. The concern is that an attacker might be able to manipulate the file path and e.g. access or delete arbitrary files. For detailed information on CWE 73, please refer to this Knowledge Article: https://community.veracode.com/s/article/how-do-i-fix-cwe-73-external-control-of-file-name-or-path-in-java.

     

    The only remediation strategies that Veracode Static Analysis is automatically able to detect here is validating the file path to access against an allow-list or hardcoding it.

     

    Otherwise, there are 2 main use cases for mitigation strategies:

    1. The whole file path comes from outside the application
    2. Only the actual file name comes from outside the application

     

    In the first scenario, the so-called "canonical path check" is usually the recommended way (an explanation plus a code snippet can be found in the above linked Knowledge Article). In the second case, we would recommend separating the actual file name from the file extension and validating both separately. The file extensions may be validated against an allow-list. For the file name, you should ideally check if it is alphanumeric (if applicable to your use case). An example regex for this would be the following: `^[a-zA-Z0-9]{1,50}$` (without the ticks). This regex would make sure that the file name is between 1 and 50 alphanumeric characters.

     

    Please note that Veracode Static Analysis cannot detect these mitigation strategies for CWE 73 and you would have to propose a mitigation and discuss it with your organization's Security Team. For more information on how to propose a mitigation, please refer to https://docs.veracode.com/r/improve_mitigation.

     

    Thank you,

    Florian Walter

    Expand Post
    • sreeramadasugiri (Community Member)

      Hi Florian,

       

      Thanksyou for replying, i am facing another issue in the same file. I am getting error for Cleartext Transmission of Sensitive Information (CWE ID 319) in my java class, FTPCoreServiceImpl.java. Please find the below actual code and changed code.

      Actual code is,

      --------------------

      client.connect(ftpMessage.getServer(), ftpMessage.getPort());

      ftpClient.login(ftp.getUserName(), ftp.getPassword());

       

      and changed code is,

      ---------------

      String ePort = ESAPI.encoder().encodeForBase64(String.valueOf(ftp.getPort()).getBytes(),true);

      ftpClient.connect(ESAPI.encoder().encodeForBase64(ftp.getHost().getBytes(),true), Integer.valueOf(new String(ESAPI.encoder().decodeFromBase64(ePort))));

      ftpClient.login(ESAPI.encoder().encodeForBase64(ftp.getUserName().getBytes(),true),ESAPI.encoder().encodeForBase64(ftp.getPassword().getBytes(),true));

       

      After changing the code i checked veracode toll for CWE id 319, but i got same issue ID 319.

      Can you help me to solve my issue with example.

       

      Regards,

      Giri

       

       

      Expand Post
      • Hi Giri,

         

        This is likely because FTP is being used as opposed to SFTP. Please always send data around via protocols that implement strong encryption.

         

        Thank you,

        Florian Walter

        Expand Post
      • sreeramadasugiri (Community Member)

        Hi Florian,

         

        Thankyou for sharing the details, happy with you.

         

        Regards,

        Giri

Topics (3)

No articles found
Loading

Ask the Community

Get answers, share a use case, discuss your favorite features, or get input from the community.