Атаки с использованием кодировки Unicode

Механизм эксплуатации строится на различии в парсинге символов на разных этапах обработки запроса. Когда Пользователь отправляет данные, Сервер может получить их в одной кодировке, а обработать в другой, если не настроена строгая конвертация. Например, отправка строки в UTF-7, которая затем конвертируется в UTF-8 внутри приложения, позволяет скрыть опасные символы от фильтров, проверяющих исходный Поток байтов. Злоумышленник использует эту разницу: то, что машина видит как безопасную последовательность, Пользователь видит как привычный текст.

Ключевым элементом является использование overlong-кодировок — избыточных последовательностей байтов, которые формально валидны по стандарту Unicode, но неожиданны для многих парсеров. Вместо одного байта для символа «A» отправляется несколько, что позволяет обойти регулярные выражения, ожидающие однобайтовый ASCII. Кроме того, применяется двойное декодирование: строка кодируется дважды (например, URL-encode + Unicode), чтобы первый Слой защиты распознал её как безобидную, а второй Слой исполнения превратил в вредоносный payload.

Визуальная часть Атаки опирается на свойства шрифтов и рендеринга браузера. Символы из разных алфавитов могут иметь идентичный глиф. Если система не проверяет фактический код точки (code point), а сравнивает визуальное Представление, она пропустит подмену. Это создает ситуацию, когда Пользователь уверенно кликает по ссылке, видя знакомый Логотип или Домен, но Транзакция происходит на стороннем сервере.

Цель применения таких методов — обход эвристических анализаторов и черных списков, которые полагаются на простое сопоставление строк. В контексте информационной безопасности это позволяет внедрить XSS-Скрипт или SQL-инъекцию в поле ввода, которое должно принимать только имена пользователей. Фильтр видит допустимые буквы и пропускает запрос, а движок базы данных получает уже декодированную команду.

Для маркетологов и специалистов по бренду Понимание этих угроз критично для защиты репутации. Мошенники создают клоны лендингов известных компаний, используя гомоглифы в доменной зоне .com или .ru. Трафик из рекламных кампаний может перенаправляться на фишинговые сайты, где собираются данные платежных карт. Без мониторинга таких подмен бренд теряет доверие клиентов, а компания несет финансовые убытки.

Также эти атаки используются для обхода систем анти-спам и модерации контента. Боты могут рассылать сообщения с запрещенными словами, записанными через похожие символы из других языков. Поисковые системы также подвержены риску индексации таких страниц, если алгоритмы не учитывают семантику Unicode, что приводит к падению качества выдачи и снижению авторитетности домена.

• Гомоглифные атаки (Homoglyph) — замена букв на визуально идентичные символы из других алфавитов (например, греческая «ε» вместо латинской «e»). Часто используется в фишинговых доменах.
• Overlong-кодировки — представление стандартного ASCII-символа через многосимвольную последовательность Unicode, которая проходит валидацию, но декодируется в оригинал на этапе выполнения.
• Двойное кодирование (Double Encoding) — многократное применение URL-encoding или Unicode-escape последовательностей для маскировки полезной нагрузки от первичных сканеров уязвимостей.
• Bidi-атаки (Bidirectional) — использование управляющих символов направления текста (LTR/RTL) для перестановки частей URL. Например, домен может отображаться справа налево, скрывая реальное имя хоста за легитимным префиксом.

Наиболее частая среда применения — веб-приложения, работающие с пользовательским вводом: формы регистрации, комментарии, поля поиска и загрузка файлов. Уязвимости проявляются, когда бэкенд-сервис принимает данные в одной кодировке (например, ISO-8859-1), а фронтенд выводит их в UTF-8 без промежуточной нормализации. Также риск высок в системах электронной почты при проверке заголовков From и Reply-To.

В интернет-маркетинге угроза актуальна для рекламных платформ и партнерских сетей. Мошенники могут использовать поддельные IDN-домены в ссылках для обхода модерации объявлений. QR-коды, ведущие на такие ресурсы, сложно проверить визуально, что делает их эффективным инструментом для социальной инженерии. Защита требует внедрения политик безопасности контента (CSP) и использования библиотек нормализации, таких как ICU.

Для демонстрации уязвимости рассмотрим пример на PHP, где строка не нормализуется перед сравнением. Злоумышленник может передать символ U+FF41 (полноширинная латинская строчная a), который визуально неотличим от обычной «a», но имеет другой код. Ниже приведен фрагмент кода, показывающий небезопасное сравнение и способ его исправления через функцию `normalizer_normalize`.

// Небезопасное сравнение: игнорирует разницу в кодовых точках
if ($input === 'admin') {
    echo 'Access granted';
}

// Безопасный подход: нормализация перед проверкой
function validateInput($string) {
    // Приводим к форме NFC (Canonical Composition)
    $normalized = normalizer_normalize($string, Normalizer::FORM_NFC);
    
    return $normalized === 'admin';
}