CWE-73: External Control of File Name or Path

Description:
The product allows user input to control or influence paths or file names that are used in filesystem operations.

Extended Description:
This could allow an attacker to access or modify system files or other files that are critical to the application. 
             Path manipulation errors occur when the following two conditions are met: 
             
                1. An attacker can specify a path used in an operation on the filesystem. 
                2. By specifying the resource, the attacker gains a capability that would not otherwise be permitted. 
             
             For example, the program may give the attacker the ability to overwrite the specified file or run with a configuration controlled by the attacker.

Affected languages: Not Language-Specific
Parent weaknesses: CWE-642, CWE-610, CWE-20

Consequences:
  - Integrity: Read Files or Directories
  - Integrity: Modify Files or Directories
  - Availability: DoS: Crash, Exit, or Restart

Detection methods:
  - Automated Static Analysis: The external control or influence of filenames can often be detected using automated static analysis that models data flow within the product. 
                   Automated static analysis might not b

Mitigations:
  - [Architecture and Design] When the set of filenames is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames, and reject all other inputs. For example, ID 1 could map to "inbox.txt" and ID 2 could map to "profile.txt". Features such as the ESAPI AccessReferenceMap p
  - [Architecture and Design] Run your code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict all access to files within a particular directory. 
                   Examples include the Unix chroot jail and AppArmor. In general, 
  - [Architecture and Design] For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-s
  - [Implementation] Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. 
                   When pe

Demonstrative examples:
The following code uses input from an HTTP request to create a file name. The programmer has not considered the possibility that an attacker could provide a file name such as "../../tomcat/conf/server.xml", which causes the application to delete one of its own configuration files (CWE-22).

String rName = request.getParameter("reportName"); File rFile = new File("/usr/local/apfr/reports/" + rName); ... rFile.delete();

The following code uses input from a configuration file to determine which file to open and echo back to the user. If the program runs with privileges and malicious users can change the configuration file, they can use the program to read any file on the system that ends with the extension .txt.

fis = new FileInputStream(cfg.getProperty("sub")+".txt"); amt = fis.read(arr); out.println(arr);

Real-world examples:
  - CVE-2022-45918: Chain: a learning management tool debugger uses external input to locate previous session logs (CWE-73) and does not properly validate the given path (CWE-20), allowing for filesystem path traversal u
  - CVE-2008-5748: Chain: external control of values for user's desired language and theme enables path traversal.
  - CVE-2008-5764: Chain: external control of user's target language enables remote file inclusion.