Unicode Normalization

Це резюме: 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 після нормалізації буде 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 шаблон

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

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

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

Фуззинг Регулярних Висловлювань

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

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

Посилання

• 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