Partager via

Considérations relatives à la sécurité : Fonctionnalités internationales

  • Article

Cette rubrique fournit des informations sur les considérations de sécurité relatives aux fonctionnalités de support international. Vous pouvez l’utiliser comme point de départ, puis consulter la documentation relative à la technologie internationale d’intérêt pour les considérations de sécurité spécifiques à la technologie.

Cette rubrique contient les sections suivantes.

Considérations relatives à la sécurité pour les fonctions de conversion de caractères

MultiByteToWideChar et WideCharToMultiByte sont les fonctions Unicode et jeu de caractères les plus couramment utilisées pour convertir des caractères entre ANSI et Unicode. Ces fonctions peuvent entraîner des risques de sécurité, car elles comptent les éléments des mémoires tampons d’entrée et de sortie différemment. Par exemple, MultiByteToWideChar prend une mémoire tampon d’entrée comptée en octets et place les caractères convertis en mémoire tampon dimensionnée en caractères Unicode. Lorsque votre application utilise cette fonction, elle doit dimensionner correctement les mémoires tampons pour éviter un dépassement de mémoire tampon.

WideCharToMultiByte correspond par défaut au mappage « le mieux adapté » pour les pages de codes, telles que 1252. Toutefois, ce type de mappage autorise plusieurs représentations de la même chaîne, ce qui risque de laisser votre application vulnérable aux attaques. Par exemple, la lettre majuscule latine A avec dierèse (« Ä ») peut mapper à la lettre majuscule latine A (« A ») ; Un caractère Unicode dans une langue asiatique peut être mappé à une barre oblique (« / »). L’utilisation de l’indicateur de WC_NO_BEST_FIT_CHARS est préférée du point de vue de la sécurité.

Certaines pages de codes, par exemple, les pages de codes 5022x (iso-2022-x), sont intrinsèquement non sécurisées, car elles autorisent plusieurs représentations de la même chaîne. Le code correctement écrit effectue des vérifications de sécurité au format Unicode, mais ces types de pages de code développent la sensibilité aux attaques de vos applications et doivent être évités si possible.

Considérations relatives à la sécurité pour les fonctions de comparaison

Les comparaisons de chaînes peuvent potentiellement présenter des problèmes de sécurité. Étant donné que toutes les fonctions de comparaison sont légèrement différentes, une fonction peut signaler deux chaînes comme égales, tandis qu’une autre fonction peut les considérer comme distinctes. Voici plusieurs fonctions que vos applications peuvent utiliser pour comparer des chaînes :

  • lstrcmpi. Compare deux chaînes de caractères en fonction des règles des paramètres régionaux, sans respect de la casse. La fonction compare les chaînes en vérifiant les premiers caractères les uns par rapport aux autres, les deuxièmes caractères entre eux, et ainsi de suite, jusqu’à ce qu’il trouve une inégalité ou atteigne les extrémités des chaînes.
  • lstrcmp. Compare les chaînes à l’aide de techniques similaires à celles de lstrcmpi. La seule différence est que lstrcmp effectue une comparaison de chaînes sensibles à la casse.
  • CompareString, CompareStringEx (Windows Vista et versions ultérieures). Effectuez une comparaison de chaînes sur des paramètres régionaux fournis par l’application. CompareStringEx est similaire à CompareString, mais il identifie les paramètres régionaux par nom de paramètres régionaux au lieu de identificateur de paramètres régionaux. Ces fonctions sont similaires à lstrcmpi et lstrcmp, sauf qu’elles fonctionnent sur des paramètres régionaux spécifiques au lieu d’un paramètre régional sélectionné par l’utilisateur.
  • CompareStringOrdinal (Windows Vista et versions ultérieures). Compare deux chaînes Unicode pour tester l’équivalence binaire. À l’exception de l’option ne respectant pas la casse, cette fonction ignore toutes les équivalences non binaires et teste tous les points de code pour l’égalité, y compris les points de code qui ne sont pas pondérés dans les de tri schémas linguistiques. Notez que les autres fonctions de comparaison mentionnées dans cette rubrique ne testent pas tous les points de code pour l’égalité.
  • FindNLSString, FindNLSStringEx (Windows Vista et versions ultérieures). Recherchez une chaîne Unicode dans une autre chaîne Unicode. FindNLSStringEx est similaire à FindNLSString, sauf qu’il identifie des paramètres régionaux par nom de paramètres régionaux au lieu de l’identificateur de paramètres régionaux.
  • FindStringOrdinal (Windows 7 et versions ultérieures). Recherche une chaîne Unicode dans une autre chaîne Unicode. L’application doit utiliser cette fonction au lieu de FindNLSString pour toutes les comparaisons non linguistiques.

Comme lstrcmpi et lstrcmp, CompareString évalue les chaînes par caractère. Toutefois, de nombreux langages ont des éléments à caractères multiples, par exemple, l’élément à deux caractères « CH » en espagnol traditionnel. Étant donné que CompareString utilise les paramètres régionaux fournis par l’application pour identifier les éléments à caractères multiples et lstrcmpi et lstrcmp utiliser les paramètres régionaux du thread, les chaînes identiques peuvent ne pas comparer comme égales.

CompareString ignore les caractères non définis et retourne donc zéro (indiquant des chaînes égales) pour de nombreuses paires de chaînes qui sont assez distinctes. Une chaîne peut contenir des valeurs qui ne correspondent à aucun caractère ou qui peuvent contenir des caractères avec une sémantique en dehors du domaine de l’application, comme les caractères de contrôle dans une URL. Les applications utilisant cette fonction doivent fournir des gestionnaires d’erreurs et des chaînes de test pour s’assurer qu’elles sont valides avant de les utiliser.

Note

Pour Windows Vista et versions ultérieures, CompareStringEx est similaire à CompareString. Les problèmes de sécurité sont identiques pour ces fonctions.

 

Des problèmes de sécurité similaires s’appliquent aux fonctions, telles que FindNLSString, qui effectuent des comparaisons implicites. Selon les indicateurs définis, les résultats de l’appel FindNLSString pour rechercher une chaîne dans une autre chaîne peuvent différer considérablement.

Note

Pour Windows Vista et versions ultérieures, FindNLSStringEx est similaire à FindNLSString. Les problèmes de sécurité sont identiques pour ces fonctions.

 

Considérations relatives à la sécurité pour les jeux de caractères dans les noms de fichiers

La page de codes Windows et les jeux de caractères OEM utilisés sur les systèmes japonais contiennent le symbole Yen (>) au lieu d’une barre oblique inverse (\). Ainsi, le caractère Yen est un caractère interdit pour les systèmes de fichiers NTFS et FAT. Lors du mappage d’Unicode à une page de codes de langue japonaise, les fonctions de conversion mappent les deux barres obliques inverses (U+005C) et le symbole Unicode Yen normal (U+00A5) à ce même caractère. Pour des raisons de sécurité, vos applications ne doivent généralement pas autoriser le caractère U+00A5 dans une chaîne Unicode qui peut être convertie en tant que nom de fichier FAT.

Considérations relatives à la sécurité pour les noms de domaine internationalisés

Les noms de domaine internationalisés (IDN) sont spécifiés par le groupe de travail réseau RFC 3490 : internationalisation des noms de domaine dans les applications (IDNA). La norme introduit un certain nombre de problèmes de sécurité.

Les Glyphes représentant certains caractères provenant de différents scripts peuvent apparaître similaires ou même identiques. Par exemple, dans de nombreuses polices, la minuscule cyrillique A (« a ») est indistinguishable de la minuscule latine A (« a »). Il n’existe aucun moyen de dire visuellement que « example.com » et « example.com » sont deux noms de domaine différents, un avec un minuscule A latin dans le nom, l’autre avec une minuscule A cyrillique. Un site hôte sans scrupule peut utiliser cette ambiguïté visuelle pour prétendre être un autre site dans une attaque d’usurpation d’identité.

Le jeu de caractères étendu que l’IDNA autorise pour les IDN a également un potentiel d’usurpation au sein d’un script particulier. Par exemple, il existe une ressemblance forte entre le trait d’union -moins (« - » U+002D), le trait d’union (« — » U+2010), le trait d’union non cassant (« - » U+2011), le tiret de figure (« \u2012 » U+2012), le tiret en (« - » U+2013) et le signe moins (« − » U+2212).

Des problèmes similaires proviennent de certaines compositions de compatibilité. Par exemple, le caractère Unicode UNIQUE NUMBER TWENTY FULL STOP (« 20 ». U+249B) est converti en « 20 ». (U+0032 U+0030 U+002E) dans une étape NamePrep, avant la conversion en Punycode. En d’autres termes, cette composition insère un point (arrêt complet). Ces compositions ont un potentiel d’usurpation d’identité.

Le mélange de différents scripts dans un IDN n’indique pas nécessairement l’usurpation ou l’intention trompeuse. Rapport technique #36 : Considérations de sécurité Unicode donne plusieurs exemples d’IDN raisonnables qui contiennent un mélange de scripts, tels que XML-Документы.com (« Документы » est russe pour « documents »).

Les attaques d’usurpation d’identité ne sont pas limitées aux IDN. Par exemple, « rnicrosoft.com » ressemble beaucoup à « microsoft.com », mais il s’agit d’un nom ASCII. En outre, une attaque d’usurpation peut être effectuée par corruption d’un nom. L’ajout d’étiquettes supplémentaires après un nom de marque connu ou l’inclusion du nom de marque dans le chemin d’une URL étiquetée comme sécurisée, peut confondre les utilisateurs novices, indépendamment de l’utilisation de l’IDN. Pour certains paramètres régionaux, les IDN sont requis et la forme Punycode de ces noms est inacceptable, car il rend les noms ressemblent à du gibberish.

Pour plus d’informations sur les problèmes de sécurité mentionnés ici, ainsi qu’un grand nombre d’autres problèmes relatifs à IDNA, consultez Rapport technique #36 : Considérations relatives à la sécurité Unicode. Outre des discussions détaillées sur les problèmes de sécurité liés à l’IDNA, ce rapport propose des suggestions pour traiter les IDN suspects dans vos applications.

Considérations relatives à la sécurité pour les fonctions ANSI

Note

Vous êtes recommandé d’utiliser Unicode dans vos applications globalisées, en particulier les nouvelles, si possible. Vous devez utiliser des fonctions ANSI uniquement si vous avez substitué des raisons de ne pas utiliser Unicode, par exemple, la conformité à un protocole plus ancien qui ne prend pas en charge Unicode.

 

De nombreuses fonctions NLS (National Language Support), telles que GetLocaleInfo et GetCalendarInfo, ont des versions ANSI spécifiques, dans ce cas, GetLocaleInfoA et GetCalendarInfoA, respectivement. Lorsque votre application utilise la version ANSI d’une fonction avec un système d’exploitation Unicode, tel que Windows NT, Windows 2000, Windows XP ou Windows Vista, la fonction peut échouer ou produire des résultats non définis. Si vous avez une raison convaincante d’utiliser des fonctions ANSI avec un tel système d’exploitation, vérifiez que les données transmises par votre application sont valides pour ANSI.

Considérations relatives à la sécurité pour la normalisation Unicode

Étant donné que la normalisation Unicode peut changer la forme d’une chaîne, les mécanismes de sécurité ou les algorithmes de validation de caractères doivent généralement être implémentés après la normalisation. Par exemple, considérez une application avec une interface web qui accepte un nom de fichier, mais n’accepte pas de nom de chemin d’accès. U+FF43 U+FF1A U+FF3C U+FF57 U+FF49 U+FF4E U+FF44 U+FF4F U+FF4F U+FF57 U+FF53 (c : \ w i n d o w s) modifications apportées à U+0063 U+0 U+003C U+0077 U+0069 U+006E U+0064 U+006F U+0077 U+0077 U+0073 (c:\windows) sous forme de normalisation KC. Si une application teste la présence des caractères deux-points et des barres obliques inverses avant qu’elle n’implémente la normalisation, le résultat peut être un accès involontaire aux fichiers.

Bien que la normalisation Unicode soit un élément dans la sécurisation des systèmes d’exploitation, n’oubliez pas que la normalisation n’est pas un remplacement pour une stratégie de sécurité complète.

jeux de caractères utilisés dans les noms de fichiers

Conventions pour les prototypes de fonction

gestion du tri dans vos applications

gestion des noms de domaine internationalisés (IDN)

Unicode