hacktricks/pentesting-web/unicode-injection
2024-09-04 13:37:30 +00:00
..
README.md Translated ['generic-methodologies-and-resources/basic-forensic-methodol 2024-07-19 10:19:44 +00:00
unicode-normalization.md Translated ['README.md', 'crypto-and-stego/hash-length-extension-attack. 2024-09-04 13:37:30 +00:00

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
{% 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:

{% 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
{% endhint %}