# Unicode Injection

{{#include ../../banners/hacktricks-training.md}}

## 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** auf irgendeine Weise **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:

{{#ref}}
unicode-normalization.md
{{#endref}}

## `\u` zu `%`

Unicode-Zeichen werden normalerweise mit dem **`\u`-Präfix** dargestellt. Zum Beispiel ist das Zeichen `㱋` `\u3c4b`([hier überprüfen](https://unicode-explorer.com/c/3c4B)). 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/](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](https://www.youtube.com/watch?v=aUsAHb0E7Cg).

## Emoji-Injektion

Backends verhalten sich manchmal seltsam, wenn sie **Emojis empfangen**. Das ist, was in [**diesem Bericht**](https://medium.com/@fpatrik/how-i-found-an-xss-vulnerability-via-using-emojis-7ad72de49209) passiert ist, wo der Forscher es geschafft hat, ein XSS mit einer Payload 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 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
<?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://github.com/iorch/jakaton_feminicidios/blob/master/data/emojis.csv)
- [https://unicode.org/emoji/charts-14.0/full-emoji-list.html](https://unicode.org/emoji/charts-14.0/full-emoji-list.html)

## Windows Best-Fit/Worst-fit

Wie in **[diesem großartigen Beitrag](https://blog.orange.tw/posts/2025-01-worstfit-unveiling-hidden-transformers-in-windows-ansi/)** erklärt, hat Windows eine Funktion namens **Best-Fit**, die **Unicode-Zeichen** ersetzt, die im ASCII-Modus nicht angezeigt werden können, durch ein ähnliches Zeichen. Dies kann zu **unerwartetem Verhalten** führen, wenn das Backend **ein bestimmtes Zeichen** erwartet, aber ein anderes erhält.

Es ist möglich, Best-Fit-Zeichen in **[https://worst.fit/mapping/](https://worst.fit/mapping/)** zu finden.

Da Windows normalerweise Unicode-Zeichenfolgen in ASCII-Zeichenfolgen als einen der letzten Teile der Ausführung konvertiert (normalerweise von einer "W"-suffixed API zu einer "A"-suffixed API wie `GetEnvironmentVariableA` und `GetEnvironmentVariableW`), würde dies Angreifern ermöglichen, Schutzmaßnahmen zu umgehen, indem sie Unicode-Zeichen senden, die zuletzt in ASCII-Zeichen konvertiert werden, die unerwartete Aktionen ausführen würden.

Im Blogbeitrag werden Methoden vorgeschlagen, um Schwachstellen zu umgehen, die mit einer **Blacklist von Zeichen** behoben wurden, **Pfadtraversalen** unter Verwendung von [Zeichen, die auf “/“ (0x2F) abgebildet sind](https://worst.fit/mapping/#to%3A0x2f) und [Zeichen, die auf “\“ (0x5C) abgebildet sind](https://worst.fit/mapping/#to%3A0x5c) oder sogar Schutzmaßnahmen gegen Shell-Escape wie PHPs `escapeshellarg` oder Pythons `subprocess.run` zu umgehen, indem eine Liste verwendet wird. Dies wurde beispielsweise mit **Vollbreiten-Doppel-Anführungszeichen (U+FF02)** anstelle von Doppel-Anführungszeichen durchgeführt, sodass am Ende das, was wie 1 Argument aussah, in 2 Argumente umgewandelt wurde.

**Beachten Sie, dass eine App anfällig sein muss, um "W" Windows-APIs zu verwenden, aber schließlich eine "A" Windows-API aufzurufen, damit das "Best-Fit" der Unicode-Zeichenfolge erstellt wird.**

**Mehrere entdeckte Schwachstellen werden nicht behoben, da die Leute sich nicht einig sind, wer dieses Problem beheben sollte.**

{{#include ../../banners/hacktricks-training.md}}