Unicode Normalization

Dies ist eine Zusammenfassung von: https://appcheck-ng.com/unicode-normalization-vulnerabilities-the-special-k-polyglot/. Schau dir weitere Details an (Bilder dort entnommen).

Verständnis von Unicode und Normalisierung

Unicode-Normalisierung ist ein Prozess, der sicherstellt, dass verschiedene binäre Darstellungen von Zeichen auf denselben binären Wert standardisiert werden. Dieser Prozess ist entscheidend im Umgang mit Zeichenfolgen in der Programmierung und Datenverarbeitung. Der Unicode-Standard definiert zwei Arten von Zeichenäquivalenz:

1. Kanonische Äquivalenz: Zeichen gelten als kanonisch äquivalent, wenn sie beim Drucken oder Anzeigen dasselbe Aussehen und dieselbe Bedeutung haben.

2. Kompatibilitätsäquivalenz: Eine schwächere Form der Äquivalenz, bei der Zeichen dasselbe abstrakte Zeichen darstellen können, aber unterschiedlich angezeigt werden können.

Es gibt vier Unicode-Normalisierungsalgorithmen: NFC, NFD, NFKC und NFKD. Jeder Algorithmus verwendet kanonische und kompatible Normalisierungstechniken unterschiedlich. Für ein tieferes Verständnis kannst du diese Techniken auf Unicode.org erkunden.

Wichtige Punkte zur Unicode-Codierung

Das Verständnis der Unicode-Codierung ist entscheidend, insbesondere im Umgang mit Interoperabilitätsproblemen zwischen verschiedenen Systemen oder Sprachen. Hier sind die Hauptpunkte:

• Codepunkte und Zeichen: In Unicode wird jedem Zeichen oder Symbol ein numerischer Wert zugewiesen, der als "Codepunkt" bekannt ist.

• Byte-Darstellung: Der Codepunkt (oder das Zeichen) wird im Speicher durch ein oder mehrere Bytes dargestellt. Zum Beispiel werden LATIN-1-Zeichen (häufig in englischsprachigen Ländern) mit einem Byte dargestellt. Sprachen mit einem größeren Zeichensatz benötigen jedoch mehr Bytes zur Darstellung.

• Codierung: Dieser Begriff bezieht sich darauf, wie Zeichen in eine Reihe von Bytes umgewandelt werden. UTF-8 ist ein verbreiteter Codierungsstandard, bei dem ASCII-Zeichen mit einem Byte und bis zu vier Bytes für andere Zeichen dargestellt werden.

• Datenverarbeitung: Systeme, die Daten verarbeiten, müssen sich der verwendeten Codierung bewusst sein, um den Byte-Stream korrekt in Zeichen umzuwandeln.

• Varianten von UTF: Neben UTF-8 gibt es andere Codierungsstandards wie UTF-16 (mit mindestens 2 Bytes, bis zu 4) und UTF-32 (mit 4 Bytes für alle Zeichen).

Es ist entscheidend, diese Konzepte zu verstehen, um potenzielle Probleme, die aus der Komplexität von Unicode und seinen verschiedenen Codierungsmethoden entstehen, effektiv zu handhaben und zu mindern.

Ein Beispiel dafür, wie Unicode zwei verschiedene Bytes normalisiert, die dasselbe Zeichen darstellen:

unicodedata.normalize("NFKD","chloe\u0301") == unicodedata.normalize("NFKD", "chlo\u00e9")

Eine Liste von Unicode-Äquivalentzeichen finden Sie hier: https://appcheck-ng.com/wp-content/uploads/unicode_normalization.html und https://0xacb.com/normalization_table

Entdecken

Wenn Sie in einer Webanwendung einen Wert finden, der zurückgegeben wird, könnten Sie versuchen, ‘KELVIN SIGN’ (U+0212A) zu senden, das normalisiert zu "K" (Sie können es als %e2%84%aa senden). Wenn ein "K" zurückgegeben wird, dann wird eine Art von Unicode-Normalisierung durchgeführt.

Ein weiteres Beispiel: %F0%9D%95%83%E2%85%87%F0%9D%99%A4%F0%9D%93%83%E2%85%88%F0%9D%94%B0%F0%9D%94%A5%F0%9D%99%96%F0%9D%93%83 nach Unicode ist Leonishan.

Anfällige Beispiele

SQL Injection Filter umgehen

Stellen Sie sich eine Webseite vor, die das Zeichen ' verwendet, um SQL-Abfragen mit Benutzereingaben zu erstellen. Diese Webseite löscht als Sicherheitsmaßnahme alle Vorkommen des Zeichens ' aus der Benutzereingabe, aber nach dieser Löschung und vor der Erstellung der Abfrage, normalisiert sie die Eingabe des Benutzers mit Unicode.

Dann könnte ein böswilliger Benutzer ein anderes Unicode-Zeichen, das äquivalent zu ' (0x27) ist, wie %ef%bc%87 einfügen. Wenn die Eingabe normalisiert wird, entsteht ein einfaches Anführungszeichen und eine SQLInjection-Schwachstelle tritt auf:

Einige interessante Unicode-Zeichen

• o -- %e1%b4%bc

• r -- %e1%b4%bf

• 1 -- %c2%b9

• = -- %e2%81%bc

• / -- %ef%bc%8f

• --- %ef%b9%a3

• #-- %ef%b9%9f

• *-- %ef%b9%a1

• ' -- %ef%bc%87

• " -- %ef%bc%82

• | -- %ef%bd%9c

' or 1=1-- -
%ef%bc%87+%e1%b4%bc%e1%b4%bf+%c2%b9%e2%81%bc%c2%b9%ef%b9%a3%ef%b9%a3+%ef%b9%a3

" or 1=1-- -
%ef%bc%82+%e1%b4%bc%e1%b4%bf+%c2%b9%e2%81%bc%c2%b9%ef%b9%a3%ef%b9%a3+%ef%b9%a3

' || 1==1//
%ef%bc%87+%ef%bd%9c%ef%bd%9c+%c2%b9%e2%81%bc%e2%81%bc%c2%b9%ef%bc%8f%ef%bc%8f

" || 1==1//
%ef%bc%82+%ef%bd%9c%ef%bd%9c+%c2%b9%e2%81%bc%e2%81%bc%c2%b9%ef%bc%8f%ef%bc%8f

sqlmap-Vorlage

XSS (Cross Site Scripting)

Sie könnten eines der folgenden Zeichen verwenden, um die Webanwendung zu täuschen und eine XSS auszunutzen:

Beachten Sie, dass das erste vorgeschlagene Unicode-Zeichen beispielsweise als: %e2%89%ae oder als %u226e gesendet werden kann.

Fuzzing Regexes

Wenn das Backend Benutzereingaben mit einem Regex überprüft, könnte es möglich sein, dass die Eingabe für den Regex normalisiert wird, aber nicht für den Ort, an dem sie verwendet wird. Zum Beispiel könnte der Regex in einem Open Redirect oder SSRF die gesendete URL normalisieren, aber dann so verwenden, wie sie ist.

Das Tool recollapse **** ermöglicht es, Variationen der Eingabe zu generieren, um das Backend zu fuzzern. Für weitere Informationen überprüfen Sie das github und diesen Beitrag.

Referenzen

• https://labs.spotify.com/2013/06/18/creative-usernames/

• https://security.stackexchange.com/questions/48879/why-does-directory-traversal-attack-c0af-work

• https://jlajara.gitlab.io/posts/2020/02/19/Bypass_WAF_Unicode.html