- 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
IDS13-J. Use compatible encodings on both sides of file or network I/O
Every Java platform has a default character encoding. The available encodings are listed in the Supported Encodings document [Encodings 2006]. A conversion between characters and sequences of bytes requires a character encoding to specify the details of the conversion. Such conversions use the system default encoding in the absence of an explicitly specified encoding. When characters are converted into an array of bytes to be sent as output, transmitted across some communication channel, input, and converted back into characters, compatible encodings must be used on both sides of the conversation. Disagreement over character encodings can cause data corruption.
According to the Java API [API 2006] for the String class:
The length of the new String is a function of the charset, and for that reason may not be equal to the length of the byte array. The behavior of this constructor when the given bytes are not valid in the given charset is unspecified.
Binary data that is expected to be a valid string may be read and converted to a string by exception FIO11-EX0.
Noncompliant Code Example
This noncompliant code example reads a byte array and converts it into a String using the platform’s default character encoding. When the default encoding differs from the encoding that was used to produce the byte array, the resulting String is likely to be incorrect. Undefined behavior can occur when some of the input lacks a valid character representation in the default encoding.
FileInputStream fis = null;
try {
fis = new FileInputStream("SomeFile");
DataInputStream dis = new DataInputStream(fis);
byte[] data = new byte[1024];
dis.readFully(data);
String result = new String(data);
} catch (IOException x) {
// handle error
} finally {
if (fis != null) {
try {
fis.close();
} catch (IOException x) {
// Forward to handler
}
}
}
Compliant Solution
This compliant solution explicitly specifies the intended character encoding in the second argument to the String constructor.
FileInputStream fis = null;
try {
fis = new FileInputStream("SomeFile");
DataInputStream dis = new DataInputStream(fis);
byte[] data = new byte[1024];
dis.readFully(data);
String encoding = "SomeEncoding"; // for example, "UTF-16LE"
String result = new String(data, encoding);
} catch (IOException x) {
// handle error
} finally {
if (fis != null) {
try {
fis.close();
} catch (IOException x) {
// Forward to handler
}
}
}
Exceptions
IDS13-EX0: An explicit character encoding may be omitted on the receiving side when the data is produced by a Java application that uses the same platform and default character encoding and is communicated over a secure communication channel (see MSC00-J for more information).
Risk Assessment
Failure to specify the character encoding while performing file or network I/O can result in corrupted data.
|
Rule |
Severity |
Likelihood |
Remediation Cost |
Priority |
Level |
|
IDS13-J |
low |
unlikely |
medium |
P2 |
L3 |
Automated Detection
Sound automated detection of this vulnerability is not feasible.
Bibliography
[Encodings 2006]