German - Ht
HackTricks Training Twitter Linkedin Sponsor

Unicode Injection

Unterstütze HackTricks

Einführung

Je nachdem, wie das Back-End/Front-End reagiert, wenn es seltsame Unicode-Zeichen empfängt, könnte ein Angreifer in der Lage sein, Schutzmaßnahmen zu umgehen und beliebige Zeichen einzufügen, die zur Ausnutzung von Injektionsanfälligkeiten wie XSS oder SQLi verwendet werden könnten.

Unicode-Normalisierung

Die Unicode-Normalisierung erfolgt, wenn Unicode-Zeichen in ASCII-Zeichen normalisiert werden.

Ein häufiges Szenario dieser Art von Anfälligkeit tritt auf, wenn das System die Eingabe des Benutzers nach der Überprüfung irgendwie modifiziert. Zum Beispiel könnte in einigen Sprachen ein einfacher Aufruf, um die Eingabe in Groß- oder Kleinbuchstaben zu konvertieren, die gegebene Eingabe normalisieren und die Unicode wird in ASCII umgewandelt, wodurch neue Zeichen entstehen. Für weitere Informationen siehe:

Unicode Normalization

\u zu %

Unicode-Zeichen werden normalerweise mit dem \u-Präfix dargestellt. Zum Beispiel ist das Zeichen 㱋 \u3c4b(hier überprüfen). Wenn ein Backend das Präfix \u in % umwandelt, wird die resultierende Zeichenkette %3c4b sein, die URL-dekodiert ist: <4b. Und, wie du sehen kannst, wird ein <-Zeichen injiziert. Du könntest diese Technik verwenden, um beliebige Zeichen einzufügen, wenn das Backend anfällig ist. Überprüfe https://unicode-explorer.com/, um die benötigten Zeichen zu finden.

Diese Anfälligkeit stammt tatsächlich von einer Anfälligkeit, die ein Forscher gefunden hat. Für eine detailliertere Erklärung siehe https://www.youtube.com/watch?v=aUsAHb0E7Cg

Emoji-Injektion

Back-Ends verhalten sich manchmal seltsam, wenn sie Emojis empfangen. Das ist, was in diesem Bericht passiert ist, wo der Forscher es geschafft hat, ein XSS mit einer Nutzlast wie: 💋img src=x onerror=alert(document.domain)//💛 zu erreichen.

In diesem Fall war der Fehler, dass der Server nach dem Entfernen der bösartigen Zeichen die UTF-8-Zeichenkette von Windows-1252 nach UTF-8 konvertierte (grundsätzlich stimmte die Eingabecodierung und die Umwandlung von Codierungen nicht überein). Dadurch wird kein richtiges < erzeugt, sondern nur ein seltsames Unicode-Zeichen: ‹ ``Also nahmen sie diese Ausgabe und konvertierten sie erneut von UTF-8 nach ASCII. Dies normalisierte das ‹ zu <, so konnte der Exploit auf diesem System funktionieren. Das ist, was passiert ist:

<?php

$str = isset($_GET["str"]) ? htmlspecialchars($_GET["str"]) : "";

$str = iconv("Windows-1252", "UTF-8", $str);
$str = iconv("UTF-8", "ASCII//TRANSLIT", $str);

echo "String: " . $str;

Emoji-Listen:

Unterstütze HackTricks
PreviousTiming AttacksNextUnicode Normalization

Last updated