hacktricks/pentesting-web/unicode-injection
2024-09-04 13:38:57 +00:00
..
README.md Translated ['generic-methodologies-and-resources/basic-forensic-methodol 2024-07-19 10:20:13 +00:00
unicode-normalization.md Translated ['README.md', 'crypto-and-stego/hash-length-extension-attack. 2024-09-04 13:38:57 +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 %}

Introduction

В залежності від того, як поводиться бекенд/фронтенд, коли він отримує дивні символи unicode, зловмисник може обійти захист і впровадити довільні символи, які можуть бути використані для зловживання вразливостями ін'єкцій, такими як XSS або SQLi.

Unicode Normalization

Нормалізація Unicode відбувається, коли символи unicode нормалізуються до символів ascii.

Один з поширених сценаріїв цього типу вразливості виникає, коли система модифікує якимось чином вхідні дані користувача після їх перевірки. Наприклад, в деяких мовах простий виклик для перетворення входу на великі або малі літери може нормалізувати дані, і unicode буде перетворено на ASCII, генеруючи нові символи.
Для отримання додаткової інформації дивіться:

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

\u to %

Символи Unicode зазвичай представляються з префіксом \u. Наприклад, символ є \u3c4b(перевірте тут). Якщо бекенд перетворює префікс \u на %, отриманий рядок буде %3c4b, що при декодуванні URL є: <4b. І, як ви можете бачити, символ < впроваджено.
Ви можете використовувати цю техніку для впровадження будь-якого символу, якщо бекенд вразливий.
Перевірте https://unicode-explorer.com/, щоб знайти потрібні символи.

Ця вразливість насправді походить від вразливості, яку знайшов дослідник, для більш детального пояснення дивіться https://www.youtube.com/watch?v=aUsAHb0E7Cg

Emoji Injection

Бекенди поводяться дивно, коли вони отримують емодзі. Це сталося в цьому звіті, де дослідник зміг досягти XSS з корисним навантаженням, таким як: 💋img src=x onerror=alert(document.domain)//💛

У цьому випадку помилка полягала в тому, що сервер після видалення шкідливих символів перетворив UTF-8 рядок з Windows-1252 на UTF-8 (в основному кодування вхідних даних і перетворення кодування не збігалися). Тоді це не дає правильного <, а лише дивний unicode:
``Отже, вони взяли цей вихід і знову перетворили з UTF-8 на ASCII. Це нормалізувало до <, так працював експлойт на цій системі.
Ось що сталося:

<?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;

Списки емодзі:

{% hint style="success" %} Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Підтримайте HackTricks
{% endhint %}