Considérations relatives à la sécurité : Fonctionnalités internationales
Cette rubrique fournit des informations sur les considérations de sécurité liées 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
- Considérations relatives à la sécurité pour les fonctions de comparaison
- Considérations relatives à la sécurité des jeux de caractères dans les noms de fichiers
- Considérations relatives à la sécurité pour les noms de domaine internationalisés
- Considérations relatives à la sécurité pour les fonctions ANSI
- Considérations relatives à la sécurité pour la normalisation Unicode
Considérations relatives à la sécurité pour les fonctions de conversion de caractères
MultiByteToWideChar et WideCharToMultiByte sont les fonctions Unicode et de 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 différemment les éléments des mémoires tampons d’entrée et de sortie. Par exemple, MultiByteToWideChar prend une mémoire tampon d’entrée comptée en octets et place les caractères convertis dans une mémoire tampon dimensionnée en caractères Unicode. Lorsque votre application utilise cette fonction, elle doit dimensionner les mémoires tampons correctement pour éviter un dépassement de mémoire tampon.
WideCharToMultiByte utilise par défaut le mappage « le mieux adapté » pour les pages de codes, par exemple 1252. Toutefois, ce type de mappage permet plusieurs représentations de la même chaîne, ce qui peut rendre votre application vulnérable aux attaques. Par exemple, la lettre majuscule latine A avec dieresis (« Ä ») peut être mappée à 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 WC_NO_BEST_FIT_CHARS est préférable 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 codes étendent la vulnérabilité 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 étant é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 les uns par rapport aux autres, et ainsi de suite, jusqu’à ce qu’elle trouve une inégalité ou atteigne les extrémités des chaînes.
- lstrcmp. Compare des chaînes à l’aide de techniques similaires à celles de lstrcmpi. La seule différence est que lstrcmp effectue une comparaison de chaînes respectant la casse.
- CompareString, CompareStringEx (Windows Vista et versions ultérieures). Effectuer 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 l’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 plutôt que sur des paramètres régionaux sélectionnés par l’utilisateur.
- CompareStringOrdinal (Windows Vista et versions ultérieures). Compare deux chaînes Unicode pour tester l’équivalence binaire. À l’exception de la possibilité de ne pas respecter 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 pris en compte dans les schémas de tri linguistique. Notez que les autres fonctions de comparaison mentionnées dans cette rubrique ne testent pas l’égalité de tous les points de code.
- FindNLSString, FindNLSStringEx (Windows Vista et versions ultérieures). Recherchez une chaîne Unicode dans une autre chaîne Unicode. FindNLSStringEx est similaire à FindNLSString, à ceci près qu’il identifie les 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 caractère par caractère. Toutefois, de nombreuses langues ont des éléments à plusieurs caractères, 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 à plusieurs caractères et que lstrcmpi et lstrcmp utilisent les paramètres régionaux du thread, les chaînes identiques peuvent ne pas être comparées comme étant é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 tout à fait distinctes. Une chaîne peut contenir des valeurs qui ne correspondent à aucun caractère ou contenir des caractères avec une sémantique en dehors du domaine de l’application, comme des 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’ils sont valides avant de les utiliser.
Notes
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 de FindNLSString pour rechercher une chaîne dans une autre chaîne peuvent différer considérablement.
Notes
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é des 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 en 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 en japonais, les fonctions de conversion mappent à la fois la barre oblique inverse (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 : Internationalizing Domain Names in Applications (IDNA). La norme introduit un certain nombre de problèmes de sécurité.
Les glyphes représentant certains caractères de différents scripts peuvent sembler similaires, voire identiques. Par exemple, dans de nombreuses polices, les minuscules cyrilliques A (« a ») ne peuvent pas être reconnaissables des minuscules latines A (« a »). Il n’existe aucun moyen de dire visuellement que « example.com » et « example.com » sont deux noms de domaine différents, l’un avec un minuscule latin A dans le nom, l’autre avec un minuscule cyrillique A. Un site hôte sans scrupules 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 qu’IDNA autorise pour les IDN a également un potentiel d’usurpation d’identité au sein d’un script particulier. Par exemple, il y a une forte ressemblance 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.
Le mélange de différents scripts dans un IDN n’indique pas nécessairement l’usurpation ou l’intention trompeuse. Le rapport technique n°36 : Considérations relatives à la sécurité Unicode fournit plusieurs exemples d’IDN raisonnables qui contiennent une combinaison de scripts, tels que XML-Документы.com (« Документы » est russe pour « documents »).
Les attaques par 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 par usurpation d’identité peut être effectuée en cas d’altération d’un nom. L’ajout d’étiquettes supplémentaires après un nom de marque connu, ou l’inclusion du nom de la marque dans le chemin d’accès d’une URL étiquetée comme sécurisée, peut perturber les utilisateurs novices, quelle que soit l’utilisation de l’IDN. Pour certains paramètres régionaux, les IDN sont obligatoires et la forme Punycode de ces noms est inacceptable, car cela donne l’impression que les noms ressemblent à du charabia.
Pour plus d’informations sur les problèmes de sécurité mentionnés ici, ainsi que sur un grand nombre d’autres problèmes liés à IDNA, consultez Technical Report #36 : Unicode Security Considerations. 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
Notes
Il est recommandé d’utiliser Unicode dans vos applications globalisées, en particulier les nouvelles, si possible. Vous devez utiliser les fonctions ANSI uniquement si vous avez 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, assurez-vous 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, prenons l’exemple d’une application avec une interface web qui accepte un nom de fichier, mais qui n’accepte pas de nom de chemin d’accès. Un 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) devient U+0063 U+001A U+003C U+0077 U+0069 U+006E U+0064 U+006F U+0077 U+0073 (c:\windows) avec formulaire normalisation KC. Si une application teste la présence des deux-points et des barres obliques inverses avant d’implémenter la normalisation, le résultat peut être un accès involontaire aux fichiers.
Bien que la normalisation Unicode soit un élément de sécurisation des systèmes d’exploitation, n’oubliez pas que la normalisation ne remplace pas une stratégie de sécurité complète.
Rubriques connexes