- Rules
- Risk Assessment Summary
- IDS00-J. Sanitize untrusted data passed across a trust boundary
- IDS01-J. Normalize strings before validating them
- IDS02-J. Canonicalize path names before validating them
- IDS03-J. Do not log unsanitized user input
- IDS04-J. Limit the size of files passed to ZipInputStream
- IDS05-J. Use a subset of ASCII for file and path names
- IDS06-J. Exclude user input from format strings
- IDS07-J. Do not pass untrusted, unsanitized data to the Runtime.exec() method
- IDS08-J. Sanitize untrusted data passed to a regex
- IDS09-J. Do not use locale-dependent methods on locale-dependent data without specifying the appropriate locale
- IDS10-J. Do not split characters between two data structures
- IDS11-J. Eliminate noncharacter code points before validation
- IDS12-J. Perform lossless conversion of String data between differing character encodings
- IDS13-J. Use compatible encodings on both sides of file or network I/O
This chapter is from the book
This chapter is from the book
This chapter is from the book
IDS05-J. Use a subset of ASCII for file and path names
File and path names containing particular characters can be troublesome and can cause unexpected behavior resulting in vulnerabilities. The following characters and patterns can be problematic 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 used to surround the file name.
- Invalid character encodings: Character encodings can make it difficult to perform proper validation of file and path names. (See rule IDS11-J.)
- Name-space separation characters: Including name-space separation characters in a file or path name can cause unexpected and potentially insecure behavior.
- Command interpreters, scripts, and parsers: Some characters have special meaning when processed by a command interpreter, shell, or parser and should consequently be avoided.
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 in C resulting from a failure to deal appropriately with case sensitivity issues [VU#439395].
This rule is a specific instance of rule IDS00-J.
Noncompliant Code Example
In the following noncompliant code example, unsafe characters are used as part of a file name.
File f = new File("A\uD8AB");
OutputStream out = new FileOutputStream(f);
A platform is free to define its own mapping of unsafe characters. For example, when tested on an Ubuntu Linux distribution, this noncompliant code example resulted in the following file name:
Compliant Solution
Use a descriptive file name containing only the subset of ASCII previously described.
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 the input.
public static void main(String[] args) throws Exception {
if (args.length < 1) {
// handle 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, 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 uses a whitelist to reject unsafe file names.
public static void main(String[] args) throws Exception {
if (args.length < 1) {
// handle error
}
String filename = args[0];
Pattern pattern = Pattern.compile("[^A-Za-z0-9%&+,.:=_]");
Matcher matcher = pattern.matcher(filename);
if (matcher.find()) {
// filename contains bad chars, handle error
}
File f = new File(filename);
OutputStream out = new FileOutputStream(f);
// ...
}
All file names originating from untrusted sources must be sanitized to ensure they contain only safe characters.
Risk Assessment
Failing to use only a safe subset of ASCII can result in misinterpreted data.
|
Rule |
Severity |
Likelihood |
Remediation Cost |
Priority |
Level |
|
IDS05-J |
medium |
unlikely |
medium |
P4 |
L3 |
Related Guidelines
|
CERT C Secure Coding Standard |
MSC09-C. Character encoding–Use subset of ASCII for safety |
|
CERT C++ Secure Coding Standard |
MSC09-CPP. Character encoding–Use subset of ASCII for safety |
|
ISO/IEC TR 24772:2010 |
Choice of filenames and other external identifiers [AJN] |
|
MITRE CWE |
CWE-116. Improper encoding or escaping of output |
Bibliography
|
ISO/IEC 646-1991 |
ISO 7-bit coded character set for information interchange |
|
[Kuhn 2006] |
UTF-8 and Unicode FAQ for UNIX/Linux |
|
[Wheeler 2003] |
5.4, File Names |
|
[VU#439395] |