Unicode Injection

Reading time: 3 minutes

Einführung

Je nachdem, wie das Backend/Frontend 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 Sie sehen können, wird ein <-Zeichen injiziert.
Sie könnten diese Technik verwenden, um beliebige Zeichen einzufügen, wenn das Backend anfällig ist.
Überprüfen Sie https://unicode-explorer.com/, um die benötigten Zeichen zu finden.

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

Emoji-Injektion

Backends 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 der Codierung 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:

• https://github.com/iorch/jakaton_feminicidios/blob/master/data/emojis.csv
• https://unicode.org/emoji/charts-14.0/full-emoji-list.html