Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Every Java platform A character encoding specifies the binary representation of the coded character set.  The Java Runtime Environment (JRE) has a default character encoding that can be set at startup time, for example:

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

The available encodings are listed in the Supported Encodings document [Encodings 2014]. A conversion between characters and sequences of bytes requires a character encoding to specify the details of the conversion. Such   In the absence of an explicitly specified encoding, 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. Compatible encodings must be used when characters are output as array of bytes then input by another process and subsequently converted back to characters.

According to the Java API  [API 2014] for the String class:

...

Disagreement 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 array, the resulting String is likely to be incorrect. Unspecified The behavior can result resulting from malformed-input and unmappable-character errors is unspecified.

Code Block
bgColor#FFCCCC
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 character encoding used to create the output 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.

Code Block
bgColor#ccccff
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, "UTF-16LE");
} catch (IOException x) {
  // handle error
} finally {
  if (fis != null) {
    try {
      fis.close();
    } catch (IOException x) {
      // Forward to handler
    }
  }
}

...

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

Risk Assessment

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

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

STR04-J

low

unlikely

medium

P2

L3

Automated Detection

Sound automated detection of this vulnerability is not feasible.

Bibliography