hacktricks/pentesting-web/unicode-injection/README.md

Unicode Injection

{% hint style="success" %} Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

• Check the subscription plans!
• Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
• Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

{% endhint %}

Wprowadzenie

W zależności od tego, jak backend/frontend zachowuje się, gdy otrzymuje dziwne znaki unicode, atakujący może być w stanie obejść zabezpieczenia i wstrzyknąć dowolne znaki, które mogą być użyte do wykorzystania luk w wstrzykiwaniu, takich jak XSS lub SQLi.

Normalizacja Unicode

Normalizacja Unicode zachodzi, gdy znaki unicode są normalizowane do znaków ascii.

Jednym z powszechnych scenariuszy tego typu luki jest sytuacja, gdy system modyfikuje w jakiś sposób wejście użytkownika po jego sprawdzeniu. Na przykład, w niektórych językach proste wywołanie do zamiany wejścia na wielkie lub małe litery może znormalizować podane wejście, a unicode zostanie przekształcone na ASCII, generując nowe znaki.
Aby uzyskać więcej informacji, sprawdź:

{% content-ref url="unicode-normalization.md" %} unicode-normalization.md {% endcontent-ref %}

\u do %

Znaki unicode są zazwyczaj reprezentowane z prefiksem \u. Na przykład znak 㱋 to \u3c4b(sprawdź to tutaj). Jeśli backend przekształca prefiks \u na %, wynikowy ciąg będzie %3c4b, który po dekodowaniu URL to: <4b. I, jak widać, znak < jest wstrzykiwany.
Możesz użyć tej techniki do wstrzyknięcia dowolnego znaku, jeśli backend jest podatny.
Sprawdź https://unicode-explorer.com/, aby znaleźć potrzebne znaki.

Ta luka pochodzi z rzeczywistej luki, którą odkrył badacz, aby uzyskać bardziej szczegółowe wyjaśnienie, sprawdź https://www.youtube.com/watch?v=aUsAHb0E7Cg

Wstrzykiwanie Emoji

Back-endy zachowują się dziwnie, gdy otrzymują emoji. Tak było w tym opisie, gdzie badacz zdołał osiągnąć XSS z ładunkiem takim jak: 💋img src=x onerror=alert(document.domain)//💛

W tym przypadku błąd polegał na tym, że serwer po usunięciu złośliwych znaków przekonwertował ciąg UTF-8 z Windows-1252 na UTF-8 (w zasadzie kodowanie wejścia i konwersja kodowania były niezgodne). Wtedy to nie daje poprawnego <, tylko dziwne unicode: ‹
``Więc wzięli ten wynik i przekonwertowali ponownie z UTF-8 na ASCII. To znormalizowało ‹ do <, w ten sposób exploit mógł działać w tym systemie.
To, co się wydarzyło:

<?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 lists:

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

{% hint style="success" %} Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)

Wsparcie HackTricks

• Sprawdź plany subskrypcyjne!
• Dołącz do 💬 grupy Discord lub grupy telegram lub śledź nas na Twitterze 🐦 @hacktricks_live.
• Dziel się trikami hackingowymi, przesyłając PR-y do HackTricks i HackTricks Cloud repozytoriów na githubie.

{% endhint %}