File names and path names containing particular characters can be troublesome and can cause unexpected behavior leading to potential vulnerabilities. If a program allows the user to specify a file name in the creation or renaming of a file, certain checks should be made to disallow the following characters and patternsor character sequences can cause problems when used in the construction of a file or path name:
- Leading dashes: Leading dashes can cause problems when programs are called with the file name as a parameter because the first character or characters of the file name might be interpreted as an option switch.
- Control characters, such as newlines, carriage returns, and escape: Control characters in a file name can cause unexpected results from shell scripts and in logging.
- Spaces: Spaces can cause problems with scripts and when double quotes aren't are not used to surround the file name.
- Invalid character encodings: Character encodings can be a huge issuemake it difficult to perform proper validation of file and path names. (See rule IDS11-J. Sanitize non-character code points before performing other sanitization.)Perform any string modifications before validation).
- Namespace prefixing and conventions: Namespace prefixes Any characters other than letters, numbers, and punctuation designated here as portable: Other special characters are included in this recommendation because they are commonly used as separators and having them in a file name can cause unexpected and potentially insecure behavior when included in a path name.
Also, many of the punctuation characters aren't unconditionally safe for file names even if they are portably available.
These characters or patterns are primarily a problem to scripts and automated parsing, but because they are not commonly used, it is best to disallow their use to reduce potential problems. Interoperability concerns also exist because different operating systems handle file names of this sort in different ways.
Wiki Markup |
---|
As a result of the influence of MS-DOS, file names of the form {{xxxxxxxx.xxx}}, where x denotes an alphanumeric character, are generally supported by modern systems. On some platforms, file names are case sensitive; while on other platforms, they are case insensitive. VU#439395 is an example of a vulnerability resulting from a failure to deal appropriately with case sensitivity issues \[[VU#439395|AA. Bibliography#VU439395]\]. |
In addition to the letters of the English alphabet ("A" through "Z" and "a" through "z"), the digits ("0" through "9"), and the space, only the following characters are portable:
No Format |
---|
% & + , - . : = _
|
- Command interpreters, scripts, and parsers: Characters that have special meaning when processed by a command interpreter, shell, or parser.
As a result of the influence of MS-DOS, 8.3 file names of the form xxxxxxxx.xxx
, where x
denotes an alphanumeric character, are generally supported by modern systems. On some platforms, file names are case sensitive, and on other platforms, they are case insensitive. VU#439395 is an example of a vulnerability resulting from a failure to deal appropriately with case sensitivity issues [VU#439395]. Developers should generate file and path names using a safe subset of ASCII characters and, for security critical applications, only accept names that use these charactersOnly these characters should be considered for use in file and path names. This is an instance of rule IDS00-J. Sanitize untrusted data passed across a trust boundary.
Noncompliant Code Example
In the following noncompliant code example, unsafe characters are used as part of a file name.
Code Block | ||
---|---|---|
| ||
File f = new File("A\uD8AB");
OutputStream out = new FileOutputStream(f);
|
An implementation A platform is free to define its own mapping of the non-"safe" unsafe characters. For example, when tested on an Ubuntu Linux distribution, this noncompliant code example resulted in the following file name:
Code Block |
---|
A?
|
Compliant Solution
Use a descriptive file name, containing only the subset of ASCII previously described.
Code Block | ||
---|---|---|
| ||
File f = new File("name.ext");
OutputStream out = new FileOutputStream(f);
|
Noncompliant Code Example
This noncompliant code example creates a file with input from the user without sanitizing itthe input.
Code Block | ||
---|---|---|
| ||
public static void main(String[] args) throws Exception { if (args.length < 1) { // handleHandle error } File f = new File(args[0]); OutputStream out = new FileOutputStream(f); // ... } |
No checks are performed on the file name to prevent troublesome characters. If an attacker knew this code was in a program used to create or rename files that would later be used in a script or automated process of some sort, they the attacker could choose particular characters in the output file name to confuse the later process for malicious purposes.
Compliant Solution
In this compliant solution, the program This compliant solution uses a whitelist to reject file names containing unsafe file namescharacters. Further input validation may be necessary, for example, to ensure that a file or directory name does not end with a period.
Code Block | ||
---|---|---|
| ||
public static void main(String[] args) throws Exception { if (args.length < 1) { // handleHandle error } String filename = args[0]; Pattern pattern = Pattern.compile("[A^A-Za-z0-9%&+,.:=9._]"); Matcher matcher = pattern.matcher(filename); if (matcher.find()) { // File filenamename contains bad chars,; handle error } File f = new File(filename); OutputStream out = new FileOutputStream(f); // ... } |
Exceptions
FIO99-J-EX0: A program may accept a file or path name that uses "unsafe" characters provided that the developer has determined that the file is not used in a restricted sink such as a command interpreter, shell, parser,logger, or other complex subsystem that attaches a particular meaning to these Similarly, all file names originating from untrusted sources must be sanitized to ensure they contain only safe characters.
Risk Assessment
Failing to use only the a safe subset of ASCII that is guaranteed to work can result in misinterpreted data.
Recommendation Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
---|---|---|---|---|---|
IDS06IDS05-J | medium | unlikely | medium | P4 | L3 |
Automated Detection
Tool | Version | Checker | Description | ||||||
---|---|---|---|---|---|---|---|---|---|
The Checker Framework |
| Tainting Checker | Trust and security errors (see Chapter 8) |
Related Guidelines
SEI CERT C Secure Coding Standard | MSC09-C. Character Encoding - encoding: Use Subset subset of ASCII for Safetysafety |
SEI CERT C++ Secure Coding Standard | VOID MSC09-CPP. Character Encoding - encoding: Use Subset subset of ASCII for Safetysafety |
"AJN Choice of Filenames and other Other External Identifiers " [AJN] | |
CWE-116, " Improper Encoding encoding or Escaping escaping of Output" output |
Bibliography
ISO 7-bit coded character set for information interchange Bit Coded Character Set for Information Interchange | |||||
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="efb34ea1-e8bf-419e-bd82-f618f4c01b25"><ac:plain-text-body><![CDATA[ | [[Kuhn 2006 | AA. Bibliography#Kuhn 06]] | UTF-8 and Unicode FAQ for UNIX/Linux | ]]></ac:plain-text-body></ac:structured-macro> | |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="25fc9a7a-493e-42be-8e8d-507ea2ac8d7a"><ac:plain-text-body><![CDATA[ [[Wheeler 2003AA. Bibliography#Wheeler03]] | 5.4 File Names]]></ac:plain-text-body></ac:structured-macro> | ||||
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="5aaf6c72-cb82-46f1-a22d-696fbd76178c"><ac:plain-text-body><![CDATA[ | [[VU#881872 | AA. Bibliography#VU881872]] |
| ]]></ac:plain-text-body></ac:structured-macro> | |
, "File Names" | |||||
[VU#439395] |
...
IDS05-J. Limit the size of files passed to ZipInputStream IDS07-J. Do not pass untrusted, unsanitized data to the Runtime.exec() method