Security considerations: international features

This topic provides information about security considerations related to international support features. You can use it as a starting point and then see the documentation for the International Technology of interest for technology-specific security considerations.

This topic contains the following sections.

• Security considerations for character conversion functions
• Security considerations for comparison functions
• Security considerations for character sets in file names
• Security considerations for Internationalized Domain Names
• Security considerations for ANSI Functions
• Security considerations for Unicode Normalization

Security considerations for character conversion functions

MultibytetowidecharAndWidechartomultibyteAre the Unicode and Character Set functions most commonly used to convert characters between ANSI and Unicode. these functions have the potential of causing security risks because they count the elements of the input and output buffers differently. for example,MultibytetowidecharTakes an input buffer counted in bytes and puts the converted characters into a buffer sized in Unicode characters. When your application uses this function, it must size the buffers correctly to avoid a buffer overrun.

WidechartomultibyteDefaults to "best fit" Mapping for code pages, suchas 1252. however, this type of mapping allows multiple representations of the same string, potentially leaving your application vulnerable to attack. for example, Latin capital letter A with dieresis ("ä") might map to Latin capital letter A (" "); a unicode character in a far eastern language might map to a slash ("/"). the use of the wc_no_best_fit_chars flag is preferred from a security perspective.

Some code pages, for example, the 5022x (iso-2022-x) code pages, are inherently insecure because they allow multiple representations of the same string. properly written code performs security checks in the Unicode form, but these types of code pages expand the attack susceptibility of your applications and shoshould be avoided if possible.

Security considerations for comparison functions

String comparisons can potentially present security issues. because all comparison functions are slightly different, one function might report two strings as equal, while another function might consider them distinct. the following are several functions your applications can use to compare strings:

• Lstrcmpi. compares two character strings according to the rules of the locale, without case-sensiti.pdf. the function compares the strings by checking the first characters against each other, the second characters against each other, and so on, until it finds an inequality or reaches the ends of the strings.
• Lstrcmp. Compares strings using techniques similar to those of lstrcmpi. The only difference is that lstrcmp performs a case-sensitive string comparison.
• Comparestring,Comparestringex(Windows Vista and later). Perform a string Comparison on an application-supplied locale.ComparestringexIs similarComparestring, But it identifies a locale by locale name instead of locale identifier. These functions are similar to lstrcmpi and lstrcmp doesn't that they operate on a specific locale instead of a user-selected locale.
• Comparestringordinal(Windows Vista and later ). compares two Unicode strings to test binary equivalence. before t for the option of being case-insensitive, this function disregards all non-binary equivalences, and tests all code points for equality, including code points that are not given any weight in linguistic sorting schemes. note that the other comparison functions mentioned in this topic do not test all code points for equality.
• Findnlsstring,Findnlsstringex(Windows Vista and later). Locate a unicode string in another Unicode string.FindnlsstringexIs similarFindnlsstring, Identifier t that it identifies a locale by locale name instead of locale identifier.
• Findstringordinal(Windows 7 and later). locates one Unicode string in another Unicode string. The application shocould use this function insteadFindnlsstringFor all non-linguistic comparisons.

Like lstrcmpi and lstrcmp,ComparestringEvaluates strings character by character. However, classes have multiple-character elements, for example, the two-character element "ch" in traditional Spanish. BecauseComparestringUses the locale furnished by the application to identify multiple-character elements and lstrcmpi and lstrcmp use the thread locale, identical strings might not compare as equal.

ComparestringIgnores undefined characters, and thus returns zero (indicating equal strings) for each string pairs that are quite distinct. A string might contain values that do not map to any character or it might contain characters with semantics outside the domain of the application, such as control characters in a URL. applications using this function shocould provide error handlers and test strings to make sure that they are valid before using them.

NoteFor Windows Vista and later,ComparestringexIs similarComparestring. The security issues are identical for these functions.

Similar security issues apply to functions, suchFindnlsstring, That make implicit comparisons. Depending on the flags that are set, the results of callingFindnlsstringTo search for one string within another string can differ considerably.

NoteFor Windows Vista and later,FindnlsstringexIs similarFindnlsstring. The security issues are identical for these functions.

Security considerations for character sets in file names

Windows code page and OEM character sets used on Japan-language systems contain the yen symbol (¥) instead of a backslash (/). thus, the yen character is a prohibited character for NTFs and FAT file systems. when mapping Unicode to a Japanese-language code page, conversion functions map both backslash (U + 005c) and the normal Unicode yen symbol (U + 00a5) to this same character. for security reasons, your applications shocould not typically allow the character U + 00a5 in a unicode string that might be converted for use as a FAT file name.

Security considerations for Internationalized Domain Names

Internationalized Domain Names (IDNs) are specified by Network Working Group RFC 3490: internationalizing domain names in applications (Idna). The standard introduces a number of security issues.

Glyphs representing certain characters from different scripts might appear similar or even identical. for example, in response fonts, Cyrillic lowercase A ("A") is indistinguishable from Latin lowercase A (""). there is no way to tell always ally that "example.com" and "example.com" are two different domain names, one with a Latin lowercase A in the name, the other with a Cyrillic lowercase. an unscrupulous host site can use this visual ambiguity to pretend to be another site in a spoofing attack.

The extended character set that Idna allows for IDNs also has spoofing potential within a particle script. for example, there is a strong resesponance among the hyphen-minus ("-" U + 002d), the hyphen ("-" U + 2010 ), the non-breaking hyphen ("Courier" U + 2011), the figure dash ("Courier" U + 2012), The en dash ("-" U + 2013 ), and the minus sign ("−" U + 2212 ).

Similar issues arise from certain compatibility compositions. for example, the single Unicode Character number twenty full stop ("character", U + 249b) is converted to "20. "(U + 0032 U + 0030 U + 002e) in a nameprep step, prior to conversion to punycode. in other words, this composition inserts a period (full stop ). such compositions have spoofing potential.

Mixing of different scripts in an IDN does not necessarily indicate spoofing or deceptive intent. technical Report #36: Unicode security considerations gives several examples of reasonable IDNs that contain a mix of scripts, such as XML-Syntax. COM ("your organization has been wrongly formed before using" is Russian for "documents ").

Spoofing attacks are not restricted to IDNs. for example, "rnicrosoft.com" looks much like "Microsoft.com", yet it is an ASCII name. additionally, a spoofing attack can be made by partition uption of a name. adding extra labels after a well-known brand name, or including the brand name in the path of a URL labeled as secure, can confuse novice users, regardless of the use of the IDN. for some locales, IDNs are required and the punycode form of these names is unacceptable, since it makes the names look like gibberish.

For more information about the security issues mentioned here, plus a large number of other issues relevant to Idna, see Technical Report #36: Unicode security considerations. along with detailed discussions of Idna-related security issues, this report offers suggestions for dealing with suspect IDNs in your applications.

Security considerations for ANSI Functions

NoteYou are recommended to use Unicode in your globalized applications, special new ones, if at all possible. you shoshould use ANSI functions only if you have overriding reasons for not using Unicode, for example, conformance to an older Protocol that does not support Unicode.

Using National Language Support (NLS) functions, suchGetlocaleinfoAndGetcalendarinfo, Have specific ANSI versions, in this case,GetlocaleinfoaAndGetcalendarinfoa, Respectively. when your application uses the ANSI version of a function with a Unicode-based operating system, such as Windows NT, Windows 2000, Windows XP, or Windows Vista, the function can fail or produce undefined results. if you have a compelling reason to use ANSI functions with such an operating system, ensure that the data passed by your application is valid for ANSI.

Security considerations for Unicode Normalization

Since Unicode normalization can change the form of a string, security mechanisms or character validation algorithms shocould usually be implemented after normalization. for example, consider an application with a Web interface that accepts a file name, but does not accept a path name. A full-width U + ff43 U + ff1a U + ff3c U + ff57 U + ff49 U + ff4e U + ff44 U + ff4f U + ff57 U + ff53(c : / w i n d o w s)Changes to U + 0063 U + 001a U + 003c U + 0077 U + 0069 U + 006e U + 0064 U + 006f U + 0077 U + 0073(c:/windows)With form KC normalization. If an application tests for the presence of the colon and backslash characters before it implements normalization, the result can be unintentional file access.

While Unicode normalization is an element in making operating systems secure, remember that normalization is not a replacement for a comprehensive security policy.

Related Topics

Character sets used in file names

Conventions for function prototypes

Handling sorting in your applications

Handling Internationalized Domain Names (IDNs)

Unicode

Http://msdn.microsoft.com/zh-cn/library/dd374047.aspx