According to the [[API 06]], class Character documentation (Unicode Character Representations):
The
chardata type (and therefore the value that aCharacterobject encapsulates) are based on the original Unicode specification, which defined characters as fixed-width 16-bit entities. The Unicode standard has since been changed to allow for characters whose representation requires more than 16 bits. The range of legal code points is now U+0000 to U+10FFFF, known as Unicode scalar value.The Java 2 platform uses the UTF-16 representation in
chararrays and in theStringandStringBufferclasses. In this representation, supplementary characters are represented as a pair ofcharvalues, the first from the high-surrogates range, (\uD800-\uDBFF), the second from the low-surrogates range (\uDC00-\uDFFF).An
intvalue represents all Unicode code points, including supplementary code points. The lower (least significant) 21 bits ofintare used to represent Unicode code points and the upper (most significant) 11 bits must be zero. Unless otherwise specified, the behavior with respect to supplementary characters and surrogate char values is as follows:
- The methods that only accept a
charvalue cannot support supplementary characters. They treatcharvalues from the surrogate ranges as undefined characters. For example,Character.isLetter('\uD840')returnsfalse, even though this specific value if followed by any low-surrogate value in a string would represent a letter.- The methods that accept an
intvalue support all Unicode characters, including supplementary characters. For example,Character.isLetter(0x2F81A)returnstruebecause the code point value represents a letter (a CJK ideograph).
Security vulnerabilities may arise if an application expects input in a form that an adversary is capable of bypassing. This can happen when an application disregards supplementary characters or when it does not use combining characters appropriately. Combining characters are characters that modify other characters. Refer to the Combining Diacritical Marks chart for more details on combining characters.
Noncompliant Code Example
This noncompliant code example attempts to trim leading characters from the string. It fails to accomplish this task because Character.isLetter() does not work for supplementary and combining characters. [[Hornig 07]] (sic)
// Fails for supplementary or combining characters
public static String trim_bad1(String string) {
char ch;
for (int i = 0; i < string.length(); i += 1) {
ch = string.charAt(i);
if (!Character.isLetter(ch))
break;
}
return string.substring(i);
}
Noncompliant Code Example
This noncompliant code example ameliorates the problem by using the String.codePointAt() method which accepts an int argument. This works for supplementary characters but not for combining characters. [[Hornig 07]] (sic)
// Fails for combining characters
public static String trim_bad2(String string) {
int ch;
for (int i = 0; i < string.length(); i += Character.charCount(ch)) {
int ch = string.codePointAt(i);
if (!Character.isLetter(ch))
break;
}
return string.substring(i);
}
Compliant Solution
This compliant solution works for both supplementary and combining characters [[Hornig 07]] (sic). According to the Java API [[API 06]], class java.text.BreakIterator documentation:
The
BreakIteratorclass implements methods for finding the location of boundaries in text. Instances ofBreakIteratormaintain a current position and scan over text returning the index of characters where boundaries occur.The boundaries returned may be those of supplementary characters, combining character sequences, or ligature clusters. For example, an accented character might be stored as a base character and a diacritical mark.
public static String trim_good(String string) {
BreakIterator iter = BreakIterator.getCharacterInstance();
iter.setText(string);
for (int i = iter.first(); i != BreakIterator.DONE; i = iter.next()) {
int ch = string.codePointAt(i);
if (!Character.isLetter(ch)) {
break;
}
if (i == BreakIterator.DONE) { // first or last text boundary has been reached
return "";
} else {
return string.substring(i);
}
}
return string;
}
Risk Assessment
Failure to account for supplementary and combining characters can lead to unexpected behavior.
Rule |
Severity |
Likelihood |
Remediation Cost |
Priority |
Level |
|---|---|---|---|---|---|
MSC40-J |
low |
unlikely |
medium |
P2 |
L3 |
Automated Detection
TODO
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
References
[[API 06]] Classes Character and BreakIterator
[[Hornig 07]] Problem areas: Characters
MSC39-J. Sanitize before processing or storing user input 49. Miscellaneous (MSC) 99. The Void (VOID)