Page History

A character encoding or charset specifies the binary representation of the coded character set. Every instance of the Java Virtual Machine (JVM) has a default charset, which may or may not be one of the standard charsets. The default charset is determined during virtual-machine startup and typically depends on the locale and charset being used by the underlying operating system [API 2014]. The default character encoding can be set at startup, for example:

java -Dfile.encoding=UTF-8 ... com.x.Main

The available encodings are listed in the Supported Encodings document [Encodings 2014]. In the absence of an explicitly specified encoding, conversions use the system default encoding. Compatible encodings must be used when characters are output as an array of bytes then input by another JVM and subsequently converted back to characters Wiki Markup Every Java platform has a default character encoding. The available encodings are listed in the _Supported Encodings_ document \[[Encodings 2006|AA. Bibliography#Encodings 06]\]. Conversions 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 20062014] 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 of rule FIO11-J. Do not attempt to read raw binary data as character dataDisagreement over character encodings can result in data corruption.

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 arrayIf the byte array does not represent a string, or if it represents a string that was encoded using other than the default encoding, 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 encodingThe behavior resulting from malformed-input and unmappable-character errors is unspecified.

FileInputStream fis = null;
try {
  FileInputStream 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 errorHandle 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 used to create the string (in this example, UTF-16LE) as the second argument to the String constructor. The LE form of UTF-16 uses little-endian byte serialization (least significant byte first). Provided that the character data was encoded in UTF-16LE, it will decode correctly.

FileInputStream fis = null;
try {
  FileInputStream fis = new FileInputStream("SomeFile");
  DataInputStream dis = new DataInputStream(fis);
  byte[] data = new byte[1024];
  dis.readFully(data);
  String encodingresult = new String(data, "SomeEncodingUTF-16LE");
} catch (IOException x) {
  // Handle for example, "UTF-16LE"error
} finally {
  Stringif result(fis != new String(data, encoding);
 null) {
    try {
      fis.close();
    } catch (IOException x) {
      // handle error
}

Risk Assessment

 Forward to handler
    }
  }
}

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. Use SSLSocket rather than Socket for secure data exchange for more information).

Risk Assessment

Using incompatible encodings when communicating string data between JVMs Failure to specify the character encoding while performing file or network I/O can result in corrupted data.

Automated Detection

Sound automated detection of this vulnerability is not feasible.

Bibliography

Bibliography

...

Image Added Image Added Image AddedIDS12-J. Perform lossless conversion of String data between differing character encodings      Image Removed      IDS14-J. Do not use locale-dependent methods on locale-sensitive data without specifying the appropriate locale