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.

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

The behavior of this constructor when the given bytes are not valid in the given charset is unspecified.

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. If 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. The behavior resulting from malformed-input and unmappable-character errors is unspecified.

FileInputStream fis = null;
try {
 

Every Java platform has a default character encoding.  The codings available are listed in \[[Encodings 06|AA. Java References#Encodings 06]\]. The default encoding is used when a character is converted to a sequence of bytes and _vice versa_.  If characters are being converted into an array of bytes, output, transmitted across some medium, input, and converted back into characters then it is clearly important that the same encoding is used on both side of the conversion.

Also, see FIO02-J. Keep track of bytes read and account for character encoding while reading data.

Noncompliant Code Example

In this noncompliant code example, a byte array is read and converted into a string using the default character encoding for the platform. If this is not the same encoding as was used to produce the byte array then the resulting string will be garbage because the some of the bytes may not have valid character representations in the default encoding.

FileInputStream fis = new FileInputStream("SomeFile");
  DataInputStream dis = new DataInputStream(fis);
int bytesRead = 0;
byte[] data = new byte[1024];

bytesRead = dis.readFully(data);
  String result = new String(data);
} catch (IOException x) {
  // Handle error
} finally {
  if (bytesReadfis >!= 0null) {
   String result = new String(data try {
      fis.close();
    } catch (IOException x) {
      // Forward to handler
    }
  }
}

Compliant Solution

In this This compliant solution , explicitly specifies the encoding is explicitly specified by using the string encoding character encoding used to create the string (in this example, UTF-16LE) as the second parameter of 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.

StringFileInputStream encodingfis = "SomeEncoding" // for example, "UTF-16LE"

FileInputStreamnull;
try {
  fis = new FileInputStream("SomeFile");
  DataInputStream dis = new DataInputStream(fis);
int bytesRead = 0;
byte[] data = new byte[1024];

bytesRead = dis.readFully(data);
  String result = new String(data, "UTF-16LE");
} catch (IOException x) {
  // Handle error
} finally {
  if (bytesReadfis >!= 0null) {
     String result = new String(data, encoding);
}

Exceptions

*EX1:* If the data is coming from another Java application on the same platform and it is known that that application is using the default character encoding, then an explicit character encoding does not need to be specified on the receiving side.

Risk Assessment

try {
      fis.close();
    } catch (IOException x) {
      // 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 can result in corrupted data.

Automated Detection

...

TODO

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

References

\[[Encodings 06|AA. Java References#Encodings 06]\]

Sound automated detection of this vulnerability is not feasible.

Tool	Version	Checker	Description
The Checker Framework	Include Page The Checker Framework_V The Checker Framework_V	Tainting Checker	Trust and security errors (see Chapter 8)
SonarQube	Include Page SonarQube_V SonarQube_V	S1943	Classes and methods that rely on the default system encoding should not be used

Bibliography

...

Image Added Image Added Image AddedFIO02-J. Keep track of bytes read and account for character encoding while reading data      08. Input Output (FIO)      FIO30-J. Do not log sensitive information