Unicode Normalization

Reading time: 6 minutes

Це резюме: https://appcheck-ng.com/unicode-normalization-vulnerabilities-the-special-k-polyglot/. Перегляньте для отримання додаткових деталей (зображення взяті звідти).

Розуміння Unicode та нормалізації

Нормалізація Unicode - це процес, який забезпечує стандартизацію різних бінарних представлень символів до одного й того ж бінарного значення. Цей процес є критично важливим при роботі з рядками в програмуванні та обробці даних. Стандарт Unicode визначає два типи еквівалентності символів:

1. Канонічна еквівалентність: Символи вважаються канонічно еквівалентними, якщо вони мають однаковий вигляд і значення при друку або відображенні.
2. Еквівалентність сумісності: Слабша форма еквівалентності, де символи можуть представляти один і той же абстрактний символ, але можуть відображатися по-різному.

Існує чотири алгоритми нормалізації Unicode: NFC, NFD, NFKC та NFKD. Кожен алгоритм використовує техніки канонічної та сумісної нормалізації по-різному. Для більш глибокого розуміння ви можете дослідити ці техніки на Unicode.org.

Основні моменти щодо кодування Unicode

Розуміння кодування Unicode є важливим, особливо при вирішенні проблем сумісності між різними системами або мовами. Ось основні моменти:

• Кодові точки та символи: У Unicode кожному символу або знаку присвоюється числове значення, відоме як "кодова точка".
• Представлення байтів: Кодова точка (або символ) представлена одним або кількома байтами в пам'яті. Наприклад, символи LATIN-1 (поширені в англомовних країнах) представлені за допомогою одного байта. Однак мови з більшим набором символів потребують більше байтів для представлення.
• Кодування: Цей термін відноситься до того, як символи перетворюються в серію байтів. UTF-8 є поширеним стандартом кодування, де символи ASCII представлені за допомогою одного байта, а інші символи - до чотирьох байтів.
• Обробка даних: Системи, що обробляють дані, повинні бути обізнані про використовуване кодування, щоб правильно перетворити байтовий потік у символи.
• Варіанти UTF: Окрім UTF-8, існують інші стандарти кодування, такі як UTF-16 (використовуючи мінімум 2 байти, до 4) та UTF-32 (використовуючи 4 байти для всіх символів).

Важливо зрозуміти ці концепції, щоб ефективно обробляти та пом'якшувати потенційні проблеми, що виникають через складність Unicode та його різні методи кодування.

Приклад того, як Unicode нормалізує два різні байти, що представляють один і той же символ:

unicodedata.normalize("NFKD","chloe\u0301") == unicodedata.normalize("NFKD", "chlo\u00e9")

Список еквівалентних символів Unicode можна знайти тут: https://appcheck-ng.com/wp-content/uploads/unicode_normalization.html та https://0xacb.com/normalization_table

Виявлення

Якщо ви можете знайти в веб-додатку значення, яке відображається назад, ви можете спробувати надіслати ‘KELVIN SIGN’ (U+0212A), яке нормалізується до "K" (ви можете надіслати його як %e2%84%aa). Якщо "K" відображається назад, тоді виконується якась форма нормалізації Unicode.

Інший приклад: %F0%9D%95%83%E2%85%87%F0%9D%99%A4%F0%9D%93%83%E2%85%88%F0%9D%94%B0%F0%9D%94%A5%F0%9D%99%96%F0%9D%93%83 після unicode це Leonishan.

Вразливі приклади

Обхід фільтра SQL Injection

Уявіть веб-сторінку, яка використовує символ ' для створення SQL-запитів з введення користувача. Ця веб-сторінка, як захід безпеки, видаляє всі випадки символу ' з введення користувача, але після цього видалення і перед створенням запиту, вона нормалізує введення користувача за допомогою Unicode.

Тоді зловмисний користувач може вставити інший символ Unicode, еквівалентний ' (0x27), наприклад, %ef%bc%87, коли введення нормалізується, створюється одинарна лапка, і з'являється вразливість SQL Injection:

Деякі цікаві символи Unicode

• o -- %e1%b4%bc
• r -- %e1%b4%bf
• 1 -- %c2%b9
• = -- %e2%81%bc
• / -- %ef%bc%8f
• --- %ef%b9%a3
• #-- %ef%b9%9f
• *-- %ef%b9%a1
• ' -- %ef%bc%87
• " -- %ef%bc%82
• | -- %ef%bd%9c

' or 1=1-- -
%ef%bc%87+%e1%b4%bc%e1%b4%bf+%c2%b9%e2%81%bc%c2%b9%ef%b9%a3%ef%b9%a3+%ef%b9%a3

" or 1=1-- -
%ef%bc%82+%e1%b4%bc%e1%b4%bf+%c2%b9%e2%81%bc%c2%b9%ef%b9%a3%ef%b9%a3+%ef%b9%a3

' || 1==1//
%ef%bc%87+%ef%bd%9c%ef%bd%9c+%c2%b9%e2%81%bc%e2%81%bc%c2%b9%ef%bc%8f%ef%bc%8f

" || 1==1//
%ef%bc%82+%ef%bd%9c%ef%bd%9c+%c2%b9%e2%81%bc%e2%81%bc%c2%b9%ef%bc%8f%ef%bc%8f

sqlmap шаблон

GitHub - carlospolop/sqlmap_to_unicode_template

XSS (Міжсайтовий скриптинг)

Ви можете використати один з наступних символів, щоб обманути веб-додаток і експлуатувати XSS:

Зверніть увагу, що, наприклад, перший запропонований символ Unicode може бути надісланий як: %e2%89%ae або як %u226e

Fuzzing Regexes

Коли бекенд перевіряє введення користувача за допомогою regex, можливо, що введення нормалізується для regex, але не для того, де воно використовується. Наприклад, в Open Redirect або SSRF regex може нормалізувати надісланий URL, але потім доступатися до нього як є.

Інструмент recollapse **** дозволяє генерувати варіації введення для fuzzing бекенду. Для отримання додаткової інформації перегляньте github та цей пост.

Unicode Overflow

З цього блогу, максимальне значення байта становить 255, якщо сервер вразливий, переповнення може бути створене для виробництва конкретного та несподіваного ASCII символу. Наприклад, наступні символи будуть перетворені на A:

• 0x4e41
• 0x4f41
• 0x5041
• 0x5141

Посилання

• https://labs.spotify.com/2013/06/18/creative-usernames/
• https://security.stackexchange.com/questions/48879/why-does-directory-traversal-attack-c0af-work
• https://jlajara.gitlab.io/posts/2020/02/19/Bypass_WAF_Unicode.html
• https://portswigger.net/research/bypassing-character-blocklists-with-unicode-overflows