Sicherheitsüberlegungen: Internationale Features

  • Artikel

Dieses Thema enthält Informationen zu Sicherheitsüberlegungen im Zusammenhang mit Features des internationalen Supports. Sie können es als Ausgangspunkt verwenden und dann die Dokumentation für die internationale Technologie von Interesse für technologiespezifische Sicherheitsüberlegungen einsehen.

Dieses Thema enthält folgende Abschnitte:

Sicherheitsüberlegungen für Zeichenkonvertierungsfunktionen

MultiByteToWideChar und WideCharToMultiByte sind die Unicode- und Zeichensatzfunktionen, die am häufigsten zum Konvertieren von Zeichen zwischen ANSI und Unicode verwendet werden. Diese Funktionen haben das Potenzial, Sicherheitsrisiken zu verursachen, da sie die Elemente der Eingabe- und Ausgabepuffer unterschiedlich zählen. MultiByteToWideChar verwendet beispielsweise einen in Bytes gezählten Eingabepuffer und fügt die konvertierten Zeichen in einen Puffer in Unicode-Zeichen ein. Wenn Ihre Anwendung diese Funktion verwendet, muss sie die Puffer richtig groß dimensionieren, um einen Pufferüberlauf zu vermeiden.

WideCharToMultiByte ist standardmäßig für Codepages wie 1252 auf "Best Fit"-Zuordnung festgelegt. Diese Art der Zuordnung ermöglicht jedoch mehrere Darstellungen derselben Zeichenfolge, sodass Ihre Anwendung möglicherweise anfällig für Angriffe ist. Beispielsweise kann der lateinische Großbuchstabe A mit Dieresis ("Ä") dem lateinischen Großbuchstaben A ("A" zugeordnet werden); Ein Unicode-Zeichen in einer asiatischen Sprache kann einem Schrägstrich ("/") zugeordnet werden. Die Verwendung des WC_NO_BEST_FIT_CHARS Flags wird aus Sicherheitssicht bevorzugt.

Einige Codepages, z. B. die Codepages 5022x (iso-2022-x), sind grundsätzlich unsicher, da sie mehrere Darstellungen derselben Zeichenfolge zulassen. Richtig geschriebener Code führt Sicherheitsüberprüfungen im Unicode-Format durch, aber diese Arten von Codepages erweitern die Angriffsanfälligkeit Ihrer Anwendungen und sollten nach Möglichkeit vermieden werden.

Sicherheitsüberlegungen für Vergleichsfunktionen

Zeichenfolgenvergleiche können möglicherweise Sicherheitsprobleme darstellen. Da alle Vergleichsfunktionen geringfügig unterschiedlich sind, kann eine Funktion zwei Zeichenfolgen als gleich melden, während eine andere Funktion sie als unterschiedlich betrachtet. Im Folgenden finden Sie verschiedene Funktionen, die Ihre Anwendungen zum Vergleichen von Zeichenfolgen verwenden können:

  • lstrcmpi. Vergleicht zwei Zeichenfolgen gemäß den Regeln des Gebietsschemas ohne Sensitivität zwischen Groß-/Kleinschreibung. Die Funktion vergleicht die Zeichenfolgen, indem sie die ersten Zeichen miteinander, die zweiten Zeichen gegeneinander usw. überprüft, bis sie eine Ungleichheit findet oder die Enden der Zeichenfolgen erreicht.
  • lstrcmp. Vergleicht Zeichenfolgen mithilfe von Techniken, die denen von lstrcmpi ähneln. Der einzige Unterschied besteht darin, dass lstrcmp einen Zeichenfolgenvergleich zwischen Groß- und Kleinschreibung durchführt.
  • CompareString, CompareStringEx (Windows Vista und höher). Führen Sie einen Zeichenfolgenvergleich für ein von der Anwendung bereitgestelltes Gebietsschema aus. CompareStringEx ähnelt CompareString, identifiziert jedoch ein Gebietsschema anhand des Gebietsschemanamens anstelle des Gebietsschemabezeichners. Diese Funktionen ähneln lstrcmpi und lstrcmp , mit der Ausnahme, dass sie nicht mit einem vom Benutzer ausgewählten Gebietsschema, sondern mit einem bestimmten Gebietsschema arbeiten.
  • CompareStringOrdinal (Windows Vista und höher). Vergleicht zwei Unicode-Zeichenfolgen, um die binäre Äquivalenz zu testen. Mit Ausnahme der Option, die Groß-/Kleinschreibung zu beachten, ignoriert diese Funktion alle nicht binären Äquivalenzen und testet alle Codepunkte auf Gleichheit, einschließlich Codepunkten, denen in linguistischen Sortierschemas keine Gewichtung gegeben ist. Beachten Sie, dass die anderen in diesem Thema erwähnten Vergleichsfunktionen nicht alle Codepunkte auf Gleichheit testen.
  • FindNLSString, FindNLSStringEx (Windows Vista und höher). Suchen Sie eine Unicode-Zeichenfolge in einer anderen Unicode-Zeichenfolge. FindNLSStringEx ähnelt FindNLSString, mit der Ausnahme, dass es ein Gebietsschema anhand des Gebietsschemanamens anstelle des Gebietsschemabezeichners identifiziert.
  • FindStringOrdinal (Windows 7 und höher). Sucht eine Unicode-Zeichenfolge in einer anderen Unicode-Zeichenfolge. Die Anwendung sollte diese Funktion anstelle von FindNLSString für alle nicht linguistischen Vergleiche verwenden.

Wie lstrcmpi und lstrcmpwertet CompareString Zeichenfolgen Zeichen für Zeichen aus. Viele Sprachen weisen jedoch mehrzeichenige Elemente auf, z. B. das zweistellige Element "CH" im traditionellen Spanischen. Da CompareString das von der Anwendung bereitgestellte Gebietsschema verwendet, um elemente mit mehreren Zeichen zu identifizieren und lstrcmpi und lstrcmp das Threadgebietsschema verwenden, werden identische Zeichenfolgen möglicherweise nicht als gleich verglichen.

CompareString ignoriert undefinierte Zeichen und gibt daher null (für gleiche Zeichenfolgen) für viele Zeichenfolgenpaare zurück, die sehr unterschiedlich sind. Eine Zeichenfolge kann Werte enthalten, die keinem Zeichen zugeordnet sind, oder Zeichen mit Semantik außerhalb der Domäne der Anwendung enthalten, z. B. Steuerzeichen in einer URL. Anwendungen, die diese Funktion verwenden, sollten Fehlerhandler und Testzeichenfolgen bereitstellen, um sicherzustellen, dass sie gültig sind, bevor sie verwendet werden.

Hinweis

Für Windows Vista und höher ist CompareStringEx vergleichbar mit CompareString. Die Sicherheitsprobleme sind für diese Funktionen identisch.

 

Ähnliche Sicherheitsprobleme gelten für Funktionen wie FindNLSString, die implizite Vergleiche vornehmen. Abhängig von den festgelegten Flags können die Ergebnisse des Aufrufs von FindNLSString zum Suchen nach einer Zeichenfolge innerhalb einer anderen Zeichenfolge erheblich abweichen.

Hinweis

Für Windows Vista und höher ähnelt FindNLSStringExFindNLSString. Die Sicherheitsprobleme sind für diese Funktionen identisch.

 

Sicherheitsüberlegungen für Zeichensätze in Dateinamen

Windows-Codepage und OEM-Zeichensätze, die in japanischsprachigen Systemen verwendet werden, enthalten das Yen-Symbol (]) anstelle eines umgekehrten Schrägstrichs (\). Daher ist das Yen-Zeichen ein unzulässiges Zeichen für NTFS- und FAT-Dateisysteme. Beim Zuordnen von Unicode zu einer japanischen Codepage ordnen Konvertierungsfunktionen sowohl den umgekehrten Schrägstrich (U+005C) als auch das normale Unicode-Yen-Symbol (U+00A5) demselben Zeichen zu. Aus Sicherheitsgründen sollten Ihre Anwendungen in der Regel das Zeichen U+00A5 in einer Unicode-Zeichenfolge nicht zulassen, die zur Verwendung als FAT-Dateiname konvertiert werden kann.

Sicherheitsüberlegungen für internationalisierte Domänennamen

Internationalisierte Domänennamen (IDNs) werden von der Netzwerkarbeitsgruppe RFC 3490: Internationalisierung von Domänennamen in Anwendungen (IDNA) angegeben. Der Standard führt zu einer Reihe von Sicherheitsproblemen.

Glyphen, die bestimmte Zeichen aus verschiedenen Skripts darstellen, können ähnlich oder sogar identisch erscheinen. Beispielsweise ist in vielen Schriftarten das kyrillische Kleinbuchstabe A ("a") nicht von lateinischem Kleinbuchstaben A ("a") zu unterscheiden. Es gibt keine Möglichkeit, visuell zu sagen, dass "example.com" und "example.com" zwei verschiedene Domänennamen sind, einer mit einem lateinischen Kleinbuchstaben A im Namen, der andere mit einem kyrillischen Kleinbuchstaben A. Eine skrupellose Hostwebsite kann diese visuelle Mehrdeutigkeit verwenden, um bei einem Spoofing-Angriff vorzugeben, eine andere Website zu sein.

Der erweiterte Zeichensatz, der IDNA für IDNs zulässt, hat auch Spoofingpotenzial innerhalb eines bestimmten Skripts. Beispiel: es gibt eine starke Ähnlichkeit zwischen dem Bindestrich-Minus ("-" U+002D), dem Bindestrich ("-" U+2010), dem trennfreien Bindestrich ("-" U+20 11), der Bindestrich ("\u2012" U+2012), der En-Gedankenstrich ("–" U+2013) und das Minuszeichen ("−" U+2212).

Ähnliche Probleme ergeben sich aus bestimmten Kompatibilitätskompositionen. Beispielsweise wird das einzelne Unicode-Zeichen NUMBER TWENTY FULL STOP ("20.", U+249B) in "20" konvertiert. (U+0032 U+0030 U+002E) in einem NamePrep-Schritt vor der Konvertierung in Punycode. Mit anderen Worten, diese Komposition fügt einen Punkt (full stop) ein. Solche Kompositionen haben Spoofingpotenzial.

Das Mischen verschiedener Skripts in einem IDN weist nicht unbedingt auf Spoofing oder Täuschungsabsicht hin. Technischer Bericht Nr. 36: Überlegungen zur Unicode-Sicherheit enthält mehrere Beispiele für vernünftige IDNs, die eine Mischung aus Skripts enthalten, z. B. XML-Документы.com ("Документы" ist russisch für "Dokumente").

Spoofingangriffe sind nicht auf IDNs beschränkt. Beispielsweise sieht "rnicrosoft.com" ähnlich wie "microsoft.com" aus, ist aber ein ASCII-Name. Darüber hinaus kann ein Spoofing-Angriff durch Die Beschädigung eines Namens erfolgen. Das Hinzufügen zusätzlicher Bezeichnungen nach einem bekannten Markennamen oder das Einschließen des Markennamens in den Pfad einer als sicher gekennzeichneten URL kann unerfahrene Benutzer verwirren, unabhängig von der Verwendung des IDN. Für einige Gebietsschemas sind IDNs erforderlich, und die Punycode-Form dieser Namen ist inakzeptabel, da sie die Namen wie kauderwelsch aussehen lässt.

Weitere Informationen zu den hier erwähnten Sicherheitsproblemen sowie zu einer Großen Anzahl anderer für IDNA relevanten Probleme finden Sie unter Technical Report #36: Unicode Security Considerations( Technischer Bericht 36: Überlegungen zur Unicode-Sicherheit). Zusammen mit ausführlichen Diskussionen zu IDNA-bezogenen Sicherheitsproblemen bietet dieser Bericht Vorschläge für den Umgang mit verdächtigen IDNs in Ihren Anwendungen.

Sicherheitsüberlegungen für ANSI-Funktionen

Hinweis

Es wird empfohlen, Unicode möglichst in ihren globalisierten Anwendungen zu verwenden, insbesondere in neuen Anwendungen. Sie sollten ANSI-Funktionen nur verwenden, wenn Sie überschriebene Gründe für die Nichtverwendung von Unicode haben, z. B. Konformität mit einem älteren Protokoll, das Unicode nicht unterstützt.

 

Viele NLS-Funktionen (National Language Support), z. B. GetLocaleInfo und GetCalendarInfo, verfügen über bestimmte ANSI-Versionen, in diesem Fall GetLocaleInfoA bzw . GetCalendarInfoA. Wenn Ihre Anwendung die ANSI-Version einer Funktion mit einem Unicode-basierten Betriebssystem wie Windows NT, Windows 2000, Windows XP oder Windows Vista verwendet, kann die Funktion fehlschlagen oder zu nicht definierten Ergebnissen führen. Wenn Sie einen überzeugenden Grund haben, ANSI-Funktionen mit einem solchen Betriebssystem zu verwenden, stellen Sie sicher, dass die von Ihrer Anwendung übergebenen Daten für ANSI gültig sind.

Sicherheitsüberlegungen für die Unicode-Normalisierung

Da die Unicode-Normalisierung die Form einer Zeichenfolge ändern kann, sollten in der Regel Sicherheitsmechanismen oder Zeichenvalidierungsalgorithmen nach der Normalisierung implementiert werden. Betrachten Sie beispielsweise eine Anwendung mit einer Webschnittstelle, die einen Dateinamen akzeptiert, aber keinen Pfadnamen akzeptiert. 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) wechselt zu U+0063 U+001A U+003C U+0077 U+0069 U+006E U+0064 U+006F U+0077 U+0073 (c:\windows) mit der Form KC-Normalisierung. Wenn eine Anwendung testet, ob doppelpunkt- und umgekehrte Schrägstrichzeichen vorhanden sind, bevor die Normalisierung implementiert wird, kann das Ergebnis unbeabsichtigter Dateizugriff sein.

Obwohl die Unicode-Normalisierung ein Element ist, um Betriebssysteme sicher zu machen, denken Sie daran, dass normalisierung kein Ersatz für eine umfassende Sicherheitsrichtlinie ist.

In Dateinamen verwendete Zeichensätze

Konventionen für Funktionsprototypen

Behandeln der Sortierung in Ihren Anwendungen

Umgang mit internationalisierten Domänennamen (IDNs)

Unicode