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 Every Java platform has a default character encoding. The available encodings are listed in the Supported Encodings document \[[Encodings 2006|AA. Bibliography#Encodings 06]\]. The default encoding is used when a character is converted to a sequence of bytes and _vice versa_. When characters are converted into an array of bytes to be sent as output, transmitted across some medium, input and converted back into characters, the same encoding must be used on both sides of the conversation. Wiki Markup
According to the Java API [API 20062014] for the String
class:
The length of the new
String
is a function of the charset, and hence 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.
Also, see the related guideline FIO02-J. Keep track of bytes read and account for character encoding while reading 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.
Code Block | ||
---|---|---|
| ||
FileInputStreamFileInputStream fis = null; 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); } catch (IOException x) { // Handle error } finally { if (bytesReadfis >!= 0null) { try String{ result = new Stringfis.close(data); } catch (IOException x) { // Forward to handler } } } |
Compliant Solution
This compliant solution explicitly specifies the intended character encoding by passing it used to create the string (in this example, UTF-16LE
) as the second argument to the String
constructor (e.g. the string encoding
in this example). 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 | ||
---|---|---|
| ||
StringFileInputStream encodingfis = "SomeEncoding" // for example, "UTF-16LE" FileInputStream null; 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 >!= 0)null) { try { String result = new String(data, encoding); } |
Exceptions
fis.close();
} catch (IOException x) {
// Forward to handler
}
}
}
|
FIO03-EX1: An explicit character encoding may be omitted on the receiving side when the data was created is produced by another a Java application that both uses the same platform and and also uses the 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 IO can corrupt the Using incompatible encodings when communicating string data between JVMs 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.
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this guideline on the CERT website.
Bibliography
Wiki Markup |
---|
\[[Encodings 2006|AA. Bibliography#Encodings 06]\] |
Tool | Version | Checker | Description | ||||||
---|---|---|---|---|---|---|---|---|---|
The Checker Framework |
| Tainting Checker | Trust and security errors (see Chapter 8) | ||||||
SonarQube |
| S1943 | Classes and methods that rely on the default system encoding should not be used |
Bibliography
...
FIO02-J. Keep track of bytes read and account for character encoding while reading data 09. Input Output (FIO) FIO04-J. Canonicalize path names before validating