![[Unicode]](http://www.unicode.org/webscripts/logo60s2.gif){kind=small}
Technical
Reports|
Technical
Reports |
| Version | 2 (draft 4) |
| Editors | Mark Davis (markdavis@google.com), Michel Suignard (michel@suignard.com) |
| Date | 2010-04-16 |
| This Version | http://www.unicode.org/reports/tr39/tr39-3.html |
| Previous Version | http://www.unicode.org/reports/tr39/tr39-2.html |
| Latest Version | http://www.unicode.org/reports/tr39/ |
| Latest Proposed Update | http://www.unicode.org/reports/tr39/proposed.html |
| Revision | 3 |
Because Unicode contains such a large number of characters and incorporates the varied writing systems of the world, incorrect usage can expose programs or systems to possible security attacks. This document specifies mechanisms that can be used to detect possible security problems.
This is a draft document which may be updated, replaced, or superseded by other documents at any time. Publication does not imply endorsement by the Unicode Consortium. This is not a stable document; it is inappropriate to cite this document as other than a work in progress.
A Unicode Technical Standard (UTS) is an independent specification. Conformance to the Unicode Standard does not imply conformance to any UTS.
Please submit corrigenda and other comments with the online reporting form [Feedback]. Related information that is useful in understanding this document is found in References. For the latest version of the Unicode Standard see [Unicode]. For a list of current Unicode Technical Reports see [Reports]. For more information about versions of the Unicode Standard, see [Versions].
Unicode Technical Report #36, "Unicode Security Considerations" [UTR36] provides guidelines for detecting and avoiding security problems connected with the use of Unicode. This document specifies mechanisms that are used in that document, and can be used elsewhere. Readers should be familiar with [UTR36] before continuing. See also the Unicode FAQ on Security Issues [FAQSec].
An implementation claiming conformance to this specification must do so in conformance to the following clauses:
| C1. | An implementation claiming to implement the
General Profile for Identifiers shall do so in accordance with the specifications in Section
3.1, General Security Profile for Identifiers. Alternatively, it shall declare that it uses a modification, and provide a precise list of characters that are added to or removed from the profile. |
| C2. | An implementation claiming to implement any
of the following confusable-detection functions must do so in accordance with the
specifications in Section 4, Confusable Detection.
Alternatively, it shall declare that it uses a modification, and provide a precise list of character mappings that are added to or removed from the provided ones. |
| C3. | An implementation claiming to detect mixed
scripts must do so in accordance with the specifications in Section 5,
Mixed-Script Detection.
Alternatively, it shall declare that it uses a modification, and provide a precise specification of the differences in behavior. |
Identifiers are special-purpose strings used for identification—strings that are deliberately limited to particular repertoires for that purpose. Exclusion of characters from identifiers does not affect the general use of those characters, such as within documents. Unicode Standard Annex #31, "Identifier and Pattern Syntax" [UAX31] provides a recommended method of determining which strings should qualify as identifiers. The UAX #31 specification extends the common practice of defining identifiers in terms of letters and numbers to the Unicode repertoire.
That specification also permits other protocols to use that method as a base, and to define a profile that adds or removes characters. For example, identifiers for specific programming languages typically add some characters like "$", and remove others like "-" (because of the use as minus), while IDNA removes "_" (among others)—see Unicode Technical Standard #46, "Unicode IDNA Compatibility Processing" [UTS46], as well as [IDNA2003], and [IDNA2008].
This document provides for additional identifier profiles for environments where security is an issue. These are profiles of the extended identifiers based on properties and specifications of the Unicode Standard [Unicode], including:
The data files used in defining these profiles follow the UCD File Format, which has a semicolon-delimited list of data fields associated with given characters, with each field referenced by number. For more details, see [UCDFormat].
The file [idmod] provides data for a profile of identifiers in environments where security is at issue. The file contains a set of characters recommended to be restricted from use. It also contains a small set of characters that are recommended as additions to the list of characters defined by the XID_Start and XID_Continue properties, because they may be used in identifiers in a broader context than programming identifiers.
The restricted characters are characters not in common use, and are removed to further reduce the possibilities for visual confusion. They include the following:
The principle has been to be more conservative initially, allowing for the set to be modified in the future as requirements for characters are refined. For information on handling modifications over time, see Section 2.9.1, Backwards Compatibility in Unicode Technical Report #36, "Unicode Security Considerations" [UTR36].
In the file [idmod], Field 1 is the character in question, Field 2 is a Status (either restricted or allowed), and Field 3 is a Type. The Types are listed in Table 1, Identifier Modification Key:
| Status | Type | Description |
|---|---|---|
| restricted | default-ignorable | Characters with the Unicode property Default_Ignorable_Code_Point=True |
| restricted | historic |
Characters not in customary modern use; includes Table 4, Candidate Characters for Exclusion from Identifiers from [UAX31] |
| restricted | limited-use | Characters whose status is uncertain, or that are used in limited environments, or those in Table 5, Recommended Scripts: Limited Usage in [UAX31] |
| restricted | not-chars | Unassigned characters, private use characters, surrogates, most control characters |
| restricted | not-NFKC | Characters that cannot occur in strings normalized to NFKC. |
| restricted | not-xid | Other characters that do not qualify as default Unicode identifiers; that is, they do not have the Unicode property XID_Continue=True. |
| restricted | obsolete | Technical characters that are no longer in use; characters with the Unicode property Deprecated=True |
| restricted | technical | Technical characters |
| allowed | inclusion | Table 3, Candidate Characters for Inclusion in Identifiers in [UAX31]. See also the notes on MidLetter in [UAX29]. |
| allowed | recommended | Table 5, Recommended Scripts in [UAX31] (excluding restricted) |
Restricted characters should be treated with caution in registration, and disallowed unless there is good reason to allow them in the enviroment in question. In user interfaces for lookup of identifiers, warnings of some kind may be appropriate. For more information, see [UTR36].
When the sets of restricted and allowed characters are applied to a particular identifier syntax, modifications need to be made. For example, a particular syntax might extend the default Unicode identifier syntax by adding characters with the Unicode property XID_Continue=False, such as "$", "-", and ".". Those characters are specific to that identifier syntax, and would need to be retained even though they are not in the allowed set.
The distinctions among the Types is not strict; if there are multiple Types for restricting a character only one is given. The important characteristic is the Status: whether or not the character is restricted. As more information is gathered about characters, this data may change in successive versions. That can cause either the Status or Type to change for a particular character. Thus users of this data should be prepared for changes in successive versions, such as by having a grandfathering policy in place for registrations.
This list is also used in deriving the IDN Identifiers list given below. It is, however, designed to be applied to general environments.
Version 1 of this document defined operations and data that apply to [IDNA2003], which has been superseded by [IDNA2008] and Unicode Technical Standard #46, "Unicode IDNA Compatibility Processing" [UTS46]. The identifer modification data can be applied to whichever specification of IDNA is being used. For more information, see the [IDN FAQ].
The tables in the data file [confusables] provide a mechanism for determining when two strings are visually confusable. The data in these files may be refined and extended over time. For information on handling modifications over time, see Section 2.9.1, Backwards Compatibility in Unicode Technical Report #36, "Unicode Security Considerations" [UTR36].
The data is organized into four different tables, depending on the desired parameters. Each table provides a mapping from source characters to target strings. On the basis of this data, there are three main classes of confusable strings:
X and Y are single-script confusables if they are confusable according to the Single-Script table, and each of them is a single script string according to Section 5, Mixed-Script Detection. Examples: "so̷s" and "søs" in Latin, where the first word has the character "o" followed by the character U+0337 ( ̷ ) COMBINING SHORT SOLIDUS OVERLAY.
X and Y are mixed-script confusables if they are confusable according to the Mixed-Script table, and they are not single-script confusables. Examples: "paypal" and "paypal", where the second word has the character U+0430 ( а ) CYRILLIC SMALL LETTER A.
X and Y are whole-script confusables if they are mixed-script confusables, and each of them is a single script string. Example: "scope" in Latin and "scope" in Cyrillic.
To see whether two strings X and Y are confusable according to a given table (abbreviated as X ≅ Y), an implementation uses a transform of X called a skeleton(X) defined by:
The resulting strings skeleton(X) and skeleton(Y) are then compared. If they are identical (codepoint-for-codepoint), then X ≅ Y according to the table.
Note: The strings skeleton(X) and skeleton(Y) are not intended for display, storage or transmission. They should be thought of as an intermediate processing form, similar to a hashcode. The characters in skeleton(X) and skeleton(Y) are not guaranteed to be identifier characters.
Implementations do not have to recursively apply the mappings, because the transforms are idempotent. That is,
skeleton(skeleton(X)) = skeleton(X)
This mechanism imposes transitivity on the data, so if X ≅ Y and Y ≅ Z, then X ≅ Z. It is possible to provide a more sophisticated confusable detection, by providing a metric between given characters, indicating their "closeness." However, that is computationally much more expensive, and requires more sophisticated data, so at this point in time the simpler mechanism has been chosen. That means that in some cases the test may be overly inclusive. However the frequency of such cases in real data should be small.
Each line in the data file has the following format: Field 1 is the source, Field 2 is the target, and Field 3 is a type identifying the table. For example,
309C ; 030A ; SL #* ( ゜ → ̊ ) KATAKANA-HIRAGANA SEMI-VOICED SOUND MARK → COMBINING RING ABOVE # →ﾟ→→゚→
The types are explained in Table 2, Confusable Data Table Types. The comments provide the character names. If the data was derived via transitivity, there is an extra comment at the end. For instance, in the above example the derivation was:
To reduce security risks, it is advised that identifiers use casefolded forms, thus eliminating uppercase variants where possible. Characters with the script values COMMON or INHERITED are ignored when testing for differences in script.
Data is also provided for testing a string to see if a string X has any whole-script confusable, using the file [confusablesWS]. This file consists of a list of lines of the form:
<range>; <sourceScript>; <targetScript>; <type> #comment
The types are either L for lowercase-only, or A for any-case, where the any-case ranges are broader (including uppercase and lowercase characters). If the string is only lowercase, use the lowercase-only table. Otherwise, first test according to the any-case table, then casefold the string and test according to the lowercase-only table.
In using the data, all lines with the same sourceScript and targetScript are collected together to form a set of Unicode characters, after filtering to the allowed characters from Section 3.1, General Security Profile for Identifiers. Logically, the file is a set of tuples of the form <sourceScript, unicodeSet, targetScript>. For example, the following lines are present for Latin to Cyrillic:
0061 ; Latn; Cyrl; L # (a) LATIN SMALL LETTER A 0063..0065 ; Latn; Cyrl; L # [3] (c..e) LATIN SMALL LETTER C..LATIN SMALL LETTER E ... 0292 ; Latn; Cyrl; L # (ʒ) LATIN SMALL LETTER EZH
They logically form a tuple <Latin, [a c-e ... \u0292], Cyrillic>, which indicates that a Latin string containing characters only from that Unicode set can have a whole-script confusable in Cyrillic (lowercase-only). Note that if the implementation needs a set of allowed characters that is different from those in Section 3.1, General Security Profile for Identifiers, this process needs to be used to generate a different set of data.
To test whether a single-script string givenString has a whole-script confusable in targetScript, the following process is used:
The test is actually slightly broader than a whole-script confusable test. It tests whether the given string has a whole-script confusable string in another script, possibly with the addition or removal of common/inherited characters such as numbers and combining marks characters to both strings. In practice, however, this broadening has no significant impact.
Implementations would normally read the data into appropriate data structures in memory for processing. A quick additional optimization is to keep, for each script, a fastReject set, containing characters in the script contained in none of the unicodeSet values.
The following Java sample shows how this can be done (using the Java version of [ICU]):
/*
* For this routine, we do not care what the target scripts are,
* just whether there is at least one whole-script confusable.
*/
boolean hasWholeScriptConfusable(String s) {
int givenScript = getSingleScript(s);
if (givenScript == UScript.INVALID_CODE) {
throw new IllegalArgumentException("Not single script string");
}
UnicodeSet givenSet = new UnicodeSet()
.addAll(s)
.removeAll(commonAndInherited);
if (fastReject[givenScript].containsSome(givenSet)) return false;
UnicodeSet[] possibles = scriptToUnicodeSets[givenScript];
for (int i = 0; i < possibles.length; ++i) {
if (possibles[i].containsAll(givenSet)) return true;
}
return false;
}
The data in [confusablesWS] is built using the data in [confusables], and subject to the same caveat: The data in these files may be refined and extended over time. For information on handling that, see Section 2.9.1, Backwards Compatibility of [UTR36].
To test for mixed-script confusables, use the following process:
Example 1: "pаypаl", with Cyrillic "а"s.
There are two scripts, Latin and Cyrillic. The set of Cyrillic characters {a} has a whole-script confusable in Latin. Thus the string is a mixed-script confusable.
Example 2: "toys-я-us", with one Cyrillic character "я".
The set of Cyrillic characters {я} does not have a whole-script confusable in Latin (there is no Latin character that looks like "я", nor does the set of Latin characters {o s t u y} have a whole-script confusable in Cyrillic (there is no Cyrillic character that looks like "t" or "u"). Thus this string is not a mixed-script confusable.
Example 3: "1iνе", with a Greek "ν" and Cyrillic "е".
There are three scripts, Latin, Greek, and Cyrillic. The set of Cyrillic characters {е} and the set of Greek characters {ν} each have a whole-script confusable in Latin. Thus the string is a mixed-script confusable.
The Unicode Standard supplies information that can be used for determining the script of characters and detecting mixed-script text. The determination of script is according to the Unicode Standard Annex #24, "Script Names" [UAX24], using data from the Unicode Character Database [UCD]. For a given input string, the process is:
Common and Inherited script characters are ignored, because they are characters that are used with more than one script. For example, "abc-def" counts as a single script: the script of "-" is ignored.
The following Java sample shows how this can be done (using the Java version of [ICU]):
/**
* Returns the script of the input text. Script values of COMMON and INHERITED are ignored.
* @param source Input text.
* @return Script value found in the text.
* If more than one script value is found (ignoring COMMON and INHERITED), then UScript.INVALID_CODE is returned.
* If no script value is found (other than COMMON or INHERITED), then UScript.COMMON is returned.
*/
public static int getSingleScript(String source) {
if (source.length() == 0) return UScript.COMMON;
int lastScript = UScript.COMMON; // temporary value
int cp;
for (int i = 0; i < source.length(); i += UTF16.getCharCount(cp)) {
cp = UTF16.charAt(source, i);
int script = UScript.getScript(cp);
if (script == UScript.COMMON || script == UScript.INHERITED) {
continue;
}
if (lastScript == UScript.COMMON) {
lastScript = script;
} else if (script != lastScript) {
return UScript.INVALID_CODE;
}
}
return lastScript;
}
This formulation ignores Common and Inherited scripts, and returns an error when a string contains mixed scripts. This basic approach needs to be enhanced for more effective spoofing detection with the following additions:
There are additional enhancements that may be useful in spoof detection. This includes such mechanisms as marking strings as "mixed script" where they contain both simplified-only and traditional-only Chinese characters, using the Unihan data in the Unicode Character Database [UCD], or detecting sequences of the same nonspacing mark.
Other enhancements useful in spoof detection include the following:
As discussed in Unicode Technical Report #36, "Unicode Security Considerations" [UTR36], confusability among characters cannot be an exact science. There are many factors that make confusability a matter of degree:
In-script confusability is extremely user-dependent. For example, in the Latin script, characters with accents or appendices may look similar to the unadorned characters for some users, especially if they are not familiar with their meaning in a particular language. However, most users will have at least a minimum understanding of the range of characters in their own script, and there are separate mechanisms available to deal with other scripts, as discussed in [UTR36].
As described elsewhere, there are cases where the data may be different than expected. Sometimes this is because two characters or two strings may only be confusable in some fonts. In other cases, it is because of transitivity. For example, the dotless and dotted I are considered equivalent (ı ↔ i), because they look the same when accents such as an acute are applied to each. However, for practical implementation usage, transitivity is sufficiently important that some oddities are accepted.
The confusability tables were created by collecting a number of prospective confusables, examining those confusables according to a set of common fonts, and processing the result for transitive closure.
The prospective confusables were gathered from a number of sources. Erik van der Poel contributed a list derived from running a program over a large number of fonts to catch characters that shared identical glyphs within a font, and Mark Davis did the same more recently for fonts on Windows and the Macintosh. Volunteers from Google, IBM, Microsoft and other companies gathered other lists of characters. These included native speakers for languages with different writing systems. The Unicode compatibility mappings were also used as a source. The process of gathering visual confusables is ongoing: the Unicode Consortium welcomes submission of additional mappings. The complex scripts of South and Southeast Asia need special attention. The focus is on characters that can be in the recommended profile for identifiers, because they are of most concern.
The fonts used to assess the confusables included those used by the major operating systems in user interfaces. In addition, the representative glyphs used in the Unicode Standard were also considered. Fonts used for the user interface in operating systems are an important source, because they are the ones that will usually be seen by users in circumstances where confusability is important, such such as when using IRIS (Internationalized Resource Identifiers) and their sub-elements (such as domain names). These fonts have a number of other relevant characteristics:
Pairs of prospective confusables were removed if they were always visually distinct at common sizes, both within and across fonts. The data was then closed under transitivity, so that if X≅Y and Y≅Z, then X≅Z. In addition, the data was closed under substring operations, so that if X≅Y then AXB≅AYB. It was then processed to produce the in-script and cross-script tables, so that a single table can be used to map an input string to a resulting skeleton.
A skeleton is intended only for internal use for testing confusability of strings; the resulting text is not suitable for display to users, because it will appear to be a hodgepodge of different scripts. In particular, the result of mapping an identifier will not necessary be an identifier. Thus the confusability mappings can be used to test whether two identifiers are confusable (if their skeletons are the same), but should definitely not be used as a "normalization" of identifiers.
The data may be enhanced in future versions of this specification. For information on handling changes in data over time, see Section 2.9.1, Backwards Compatibility of [UTR36].
The following files provide data used to implement the recommendations in this document. The data may be refined in future versions of this specification. For more information, see Section 2.9.1, Backwards Compatibility of [UTR36]. The Unicode Consortium welcomes feedback on additional confusables or identifier restrictions: see [Feedback].
The files are in http://www.unicode.org/Public/security/. The directories there contain data files associated with a given version, with names such as:
The data files for the latest approved version are also in the directory:
| [data2.0] | uts39-data-xx.zip | A zipped version of all the data files. |
| [idmod] | xidmodifications.txt | Identifier Modifications: Provides the list of additions and restrictions recommended for building a profile of identifiers for environments where security is at issue. |
| [confusables] | confusables.txt | Visually Confusable Characters: Provides a mapping for visual confusables for use in detecting possible security problems. The usage of the file is described in Section 4, Confusable Detection. |
| [confusablesWS] | confusablesWholeScript.txt | Whole Script Confusables: Data for testing for the possible existence of whole-script and mixed-script confusables. See Section 4, Confusable Detection |
| [intentional] | intentional.txt | Intentional Confusable Mappings: The class of characters whose glyphs in any particular typeface would probably be designed to be identical in shape when using a harmonized typeface design. |
Mark Davis and Michel Suignard authored the bulk of the text, under direction from the Unicode Technical Committee. Steven Loomis and other people on the ICU team were very helpful in developing the original proposal for this technical report. Thanks also to the following people for their feedback or contributions to this document or earlier versions of it: Douglas Davidson, Martin Dürst, Asmus Freytag, Deborah Goldsmith, Paul Hoffman, Peter Karlsson, Gervase Markham, Eric Muller, Erik van der Poel, Michael van Riper, Marcos Sanz, Alexander Savenkov, Dominikus Scherkl, and Kenneth Whistler. Thanks to Peter Peng for his assistance with font confusables.
| [CLDR] | Unicode Locales Project (Unicode Common Locale Data Repository) http://www.unicode.org/cldr/ |
| [DCore] | Derived Core Properties http://www.unicode.org/Public/UNIDATA/DerivedCoreProperties.txt |
| [DemoConf] | http://unicode.org/cldr/utility/confusables.jsp |
| [DemoIDN] | http://unicode.org/cldr/utility/idna.jsp |
| [DemoIDNChars] | http://unicode.org/cldr/utility/list-unicodeset.jsp?a=\p{age%3D3.2}-\p{cn}-\p{cs}-\p{co}&abb=on&g=uts46+idna+idna2008 |
| [FAQSec] | Unicode FAQ on Security Issues http://www.unicode.org/faq/security.html |
| [ICU] | International Components for Unicode http://site.icu-project.org/ |
| [IDNA2003] | The IDNA2003 specification is defined by a cluster of IETF RFCs: |
| [IDNA2008] | The draft IDNA2008 specification is defined by a cluster of IETF RFCs:
There are also two informative documents:
For more information, see http://tools.ietf.org/id/idnabis. [Review Note: Once IDNA2008 is final, and final formal titles and RFC numbers will be used in references in the text.] |
| [IDN-FAQ] | http://www.unicode.org/faq/idn.html |
| [Feedback] | For suggested confusables or identifier restrictions, please see: For issues in the text, please see: |
| [Reports] | Unicode Technical Reports http://www.unicode.org/reports/ For information on the status and development process for technical reports, and for a list of technical reports. |
| [RFC3491] | Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
Profile for Internationalized Domain Names (IDN)", RFC 3491, March 2003. http://ietf.org/rfc/rfc3491.txt |
| [Security-FAQ] | http://www.unicode.org/faq/security.html |
| [UCD] | Unicode Character Database. http://www.unicode.org/ucd/ For an overview of the Unicode Character Database and a list of its associated files. |
| [UCDFormat] | UCD File Format http://www.unicode.org/reports/tr44/#Format_Conventions |
| [UAX24] | UAX #24: Script Names http://www.unicode.org/reports/tr24/ |
| [Unicode] | The Unicode Standard For the latest version, see: http://www.unicode.org/versions/latest/ For the 5.2.0 version, see: http://www.unicode.org/versions/Unicode5.2.0/ |
| [UTR36] | UTR #36: Unicode Security Considerations http://www.unicode.org/reports/tr36/ |
| [UTS18] | UTS #18: Unicode Regular Expressions http://www.unicode.org/reports/tr18/ |
| [UTS39] | UTS #39: Unicode Security Mechanisms http://www.unicode.org/reports/tr39/ |
| [UTS46] | Unicode IDNA Compatibility Processing http://www.unicode.org/reports/tr46/ |
| [Versions] | Versions of the Unicode Standard http://www.unicode.org/standard/versions/ For information on version numbering, and citing and referencing the Unicode Standard, the Unicode Character Database, and Unicode Technical Reports. |
The following summarizes modifications from the previous revision of this document.
Revision 3:
Copyright © 2004-2010 Unicode, Inc. All Rights Reserved. The Unicode Consortium makes no expressed or implied warranty of any kind, and assumes no liability for errors or omissions. No liability is assumed for incidental and consequential damages in connection with or arising out of the use of the information or programs contained or accompanying this technical report. The Unicode Terms of Use apply.
Unicode and the Unicode logo are trademarks of Unicode, Inc., and are registered in some jurisdictions.