Unicode Injection

Reading time: 4 minutes

Introduction

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

Unicode Normalization

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

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

Unicode Normalization

\u to %

Юнікодні символи зазвичай представлені з префіксом \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 (в основному кодування вхідних даних і перетворення кодування не збігалися). Тоді це не дає правильного <, а лише дивний юнікодний: ‹
``Отже, вони взяли цей вихід і знову перетворили з 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;

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

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

Windows Best-Fit/Worst-fit

Як пояснюється в цьому чудовому пості, Windows має функцію під назвою Best-Fit, яка замінює юнікодні символи, які не можуть бути відображені в ASCII-режимі, на подібні. Це може призвести до неочікуваної поведінки, коли бекенд очікує конкретний символ, але отримує інший.

Можна знайти символи best-fit у https://worst.fit/mapping/.

Оскільки Windows зазвичай конвертує юнікодні рядки в ASCII-рядки на одному з останніх етапів виконання (зазвичай переходячи з API з суфіксом "W" на API з суфіксом "A", такі як GetEnvironmentVariableA і GetEnvironmentVariableW), це дозволяє зловмисникам обходити захист, надсилаючи юнікодні символи, які в кінці будуть перетворені в ASCII-символи, що виконуватимуть неочікувані дії.

У блозі пропонуються методи обходу вразливостей, виправлених за допомогою чорного списку символів, експлуатація перетворень шляхів за допомогою символів, відображених на “/“ (0x2F) та символів, відображених на “\“ (0x5C) або навіть обходу захисту оболонки, такого як escapeshellarg у PHP або subprocess.run у Python, використовуючи список. Це було зроблено, наприклад, використовуючи повноширокі подвійні лапки (U+FF02) замість подвійних лапок, так що в кінці те, що виглядало як 1 аргумент, було перетворено на 2 аргументи.

Зверніть увагу, що для того, щоб додаток був вразливим, він повинен використовувати "W" Windows API, але в кінці викликати "A" Windows API, щоб було створено "Best-fit" юнікодного рядка.

Кілька виявлених вразливостей не будуть виправлені, оскільки люди не погоджуються, хто має виправити цю проблему.