Freigeben über

Sicherheitsaspekte: Internationale Features

  • Artikel

Dieses Thema enthält Informationen zu Sicherheitsaspekten im Zusammenhang mit den 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 anzeigen.

Dieses Thema enthält die folgenden 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. Beispielsweise verwendet MultiByteToWideChar einen in Bytes gezählten Eingabepuffer und fügt die konvertierten Zeichen in unicode-Zeichen in eine Puffergröße ein. Wenn Ihre Anwendung diese Funktion verwendet, muss sie die Puffer ordnungsgemäß anpassen, um einen Pufferüberlauf zu vermeiden.

WideCharToMultiByte standardmäßig die Zuordnung "optimal anpassen" für Codeseiten, z. B. 1252. Dieser Zuordnungstyp ermöglicht jedoch mehrere Darstellungen derselben Zeichenfolge, wodurch Ihre Anwendung potenziell anfällig für Angriffe bleibt. Beispielsweise kann der lateinische Großbuchstabe A mit Derresis ("Ä") dem lateinischen Großbuchstabe A ("A" zugeordnet sein); Ein Unicode-Zeichen in einer asiatischen Sprache kann einem Schrägstrich ("/") zugeordnet werden. Die Verwendung des WC_NO_BEST_FIT_CHARS Flags wird aus Sicherheitsgründen bevorzugt.

Einige Codeseiten, z. B. die Codeseiten 5022x (iso-2022-x), sind inhärent unsicher, da sie mehrere Darstellungen derselben Zeichenfolge zulassen. Richtig geschriebener Code führt Sicherheitsüberprüfungen im Unicode-Formular durch, aber diese Arten von Codeseiten erweitern die Angriffsempfindlichkeit Ihrer Anwendungen und sollten möglichst 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 gleich melden, während eine andere Funktion sie möglicherweise unterscheiden kann. Im Folgenden finden Sie verschiedene Funktionen, mit denen Ihre Anwendungen Zeichenfolgen vergleichen können:

  • lstrcmpi. Vergleicht zwei Zeichenzeichenfolgen gemäß den Regeln des Gebietsschemas ohne Groß-/Kleinschreibung. Die Funktion vergleicht die Zeichenfolgen, indem die ersten Zeichen gegeneinander überprüft werden, die zweiten Zeichen gegeneinander usw., 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 Vergleich zwischen Groß- und Kleinschreibung durchführt.
  • CompareString, CompareStringEx (Windows Vista und höher). Führen Sie einen Zeichenfolgenvergleich für ein vom Anwendung bereitgestelltes Gebietsschema aus. CompareStringEx- ähnelt CompareString-, identifiziert jedoch ein Gebietsschema anhand Gebietsschemanamens anstelle Gebietsschemabezeichners. Diese Funktionen ähneln lstrcmpi und lstrcmp- mit der Ausnahme, dass sie auf einem bestimmten Gebietsschema anstelle eines vom Benutzer ausgewählten Gebietsschemas ausgeführt werden.
  • CompareStringOrdinal (Windows Vista und höher). Vergleicht zwei Unicode-Zeichenfolgen zum Testen der binären Äquivalenz. Abgesehen davon, dass die Groß-/Kleinschreibung nicht beachtet wird, ignoriert diese Funktion alle nicht binären Äquivalenz und testet alle Codepunkte auf Gleichheit, einschließlich Codepunkte, die keine Gewichtung in der sprachlichen Sortierung Schemas haben. Beachten Sie, dass die in diesem Thema erwähnten anderen 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 sprachlichen Vergleiche verwenden.

Wie lstrcmpi und lstrcmpwertet CompareString Zeichenfolgenzeichen nach Zeichen aus. Viele Sprachen weisen jedoch mehrere Zeichenelemente auf, z. B. das zweistellige Element "CH" in traditionellem Spanisch. Da CompareString das von der Anwendung bereitgestellte Gebietsschema verwendet, um mehrere Zeichenelemente zu identifizieren, und lstrcmpi und lstrcmp das Threadgebietsschema verwenden, werden identische Zeichenfolgen möglicherweise nicht gleich verglichen.

CompareString- ignoriert nicht definierte Zeichen und gibt daher Null (die gleiche Zeichenfolgen angibt) für viele Zeichenfolgenpaare zurück, die ziemlich 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.

Anmerkung

Für Windows Vista und höher ähnelt CompareStringEx-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 sich die Ergebnisse des Aufrufens FindNLSString- für die Suche nach einer Zeichenfolge innerhalb einer anderen Zeichenfolge erheblich unterscheiden.

Anmerkung

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

 

Sicherheitsüberlegungen für Zeichensätze in Dateinamen

Windows-Codepage und OEM-Zeichensätze, die auf japanischen Sprachsystemen 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 Codeseite ordnen Konvertierungsfunktionen den umgekehrten Schrägstrich (U+005C) und das normale Unicode-Yen-Symbol (U+00A5) diesem Zeichen zu. Aus Sicherheitsgründen sollten Ihre Anwendungen das Zeichen U+00A5 in einer Unicode-Zeichenfolge nicht zulassen, die möglicherweise als FAT-Dateiname konvertiert werden kann.

Sicherheitsüberlegungen für internationalisierte Domänennamen

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

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

Der erweiterte Zeichensatz, den IDNA für IDNs zulässt, hat auch Spoofingpotenziale innerhalb eines bestimmten Skripts. Beispiel: es gibt eine starke Ähnlichkeit zwischen dem Bindestrich minus ("-" U+002D), dem Bindestrich ("—" U+2010), dem nicht brechenden Bindestrich ("-" U+2011), der Strich ("\u2012" U+2012), das Gedankenstrich ("–" U+2013) und das Minuszeichen ("−" U+2212).

Ähnliche Probleme treten bei bestimmten Kompatibilitätskompositionen auf. 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 (vollständiger Stopp) ein. Solche Kompositionen haben Spoofingpotenziale.

Das Mischen verschiedener Skripts in einem IDN weist nicht notwendigerweise auf Spoofing oder betrügerische Absicht 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, aber es handelt sich um einen ASCII-Namen. Darüber hinaus kann ein Spoofingangriff durch Beschädigung eines Namens gemacht werden. Das Hinzufügen zusätzlicher Bezeichnungen nach einem bekannten Markennamen oder das Einschließen des Markennamens im Pfad einer ALS sicher bezeichneten URL kann Anfänger unabhängig von der Verwendung des IDN verwirren. Für einige Gebietsschemas sind IDNs erforderlich, und die Punycode-Form dieser Namen ist inakzeptabel, da die Namen wie Gibberisch aussehen.

Weitere Informationen zu den hier erwähnten Sicherheitsproblemen sowie einer großen Anzahl anderer für IDNA relevanter Probleme finden Sie im Technischen Bericht Nr. 36: Überlegungen zur Unicode-Sicherheit. Zusammen mit detaillierten Diskussionen über IDNA-bezogene Sicherheitsprobleme bietet dieser Bericht Vorschläge für den Umgang mit verdächtigen IDNs in Ihren Anwendungen.

Sicherheitsüberlegungen für ANSI-Funktionen

Anmerkung

Sie werden empfohlen, Unicode in ihren globalisierten Anwendungen zu verwenden, insbesondere neue, wenn möglich. Sie sollten ANSI-Funktionen nur verwenden, wenn Sie Überschreibungsgründe für die Verwendung von Unicode haben, z. B. die Konformität mit einem älteren Protokoll, das Unicode nicht unterstützt.

 

Viele NLS-Funktionen (National Language Support), z. B. GetLocaleInfo und GetCalendarInfo, verfügen in diesem Fall über spezifische ANSI-Versionen, in diesem Fall GetLocaleInfoA und GetCalendarInfoA. Wenn Ihre Anwendung die ANSI-Version einer Funktion mit einem Unicode-basierten Betriebssystem verwendet, z. B. Windows NT, Windows 2000, Windows XP oder Windows Vista, kann die Funktion fehlschlagen oder nicht definierte Ergebnisse erzeugen. Wenn Sie einen zwingenden 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 Sicherheitsmechanismen oder Zeichenüberprüfungsalgorithmen in der Regel nach der Normalisierung implementiert werden. Betrachten Sie beispielsweise eine Anwendung mit einer Webschnittstelle, die einen Dateinamen akzeptiert, aber keinen Pfadnamen akzeptiert. Eine vollbreite U+FF43 U+FF1A U+FF3C U+FF57 U+FF49 U+FF4E U+FF44 U+FF44 U+FF4F U+FF57 U+FF53 (c : \ w i n d o w s) Änderungen an U+0063 U+001A U+003C U+0077 U+0069 U+006E U+0064 U+006F U+0077 U+0073 (c:\windows) mit Form KC Normalisierung. Wenn eine Anwendung auf das Vorhandensein des Doppelpunkts und umgekehrten Schrägstrichs überprüft, bevor die Normalisierung implementiert wird, kann das Ergebnis unbeabsichtigter Dateizugriff sein.

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

Zeichensätze, die in Dateinamen verwendet werden

Konventionen für Funktionsprototypen

Behandlung der Sortierung in Ihren Anwendungen

Umgang mit internationalisierten Domänennamen (IDNs)

Unicode-