WAF Bypass через JSON: как работают атаки и почему фильтры не справляются

WAF (Web Application Firewall) часто становится первой линией защиты для веб-приложений. Он фильтрует запросы, блокирует известные атаки и снижает риск компрометации. Но как только речь заходит о JSON, открываются неожиданные лазейки. Всё дело в том, что разные парсеры обрабатывают одни и те же данные по-разному. На этой разнице и строятся атаки.

Почему именно JSON и где кроется проблема

JSON создавался как простой формат для обмена данными. Но спецификация оставляет свободу, а значит — разные интерпретации. Например, в объекте могут встречаться одинаковые ключи. Какой выбрать — первый или последний? Один парсер возьмёт первое значение, другой — последнее, третий выдаст ошибку. Если WAF проверяет одно, а приложение использует другое — фильтр можно обойти.

• Разные библиотеки интерпретируют JSON по-своему.
• Нет жёсткого стандарта для дубликатов ключей.
• Символы и кодировки могут обрабатываться по-разному.

Эти расхождения превращают JSON в удобный инструмент для атакующего. Несоответствие парсеров может привести к утечкам данных и внедрению кода.

Пример атаки через дублирующие ключи

Простой пример с повторяющимся полем:

{ "user": "admin", "password": "123", "isAdmin": false, "isAdmin": true }

WAF проверяет первое значение isAdmin и видит false. Но приложение может взять последнее и увидеть true. В результате злоумышленник получает права администратора, а система защиты считает, что всё в порядке.

Такие приёмы подробно исследует PortSwigger в статье «JSON hijacking for the modern web» , где описаны техники кражи данных через JavaScript‑прокси в браузерах (например, Edge, Chrome)

Манипуляции с пробелами и кодировками

JSON поддерживает Unicode, и один и тот же символ можно записать разными способами. Например:

• u002e вместо точки.
• необычные пробелы (U+00A0 или U+2003).
• смешение UTF-8 и UTF-16.

WAF может проигнорировать такие варианты, а приложение примет их как валидные символы. Подобные обходы подробно разбирались в исследованиях, например, когда обычная запятая ломала проверку облачной защиты.

Вложенные структуры и скрытые поля

Другой приём — спрятать данные во вложенный объект. Допустим, фильтр ждёт пароль на верхнем уровне JSON, а злоумышленник помещает его глубже:

{ "user": "admin", "data": { "password": "123456" } }

Некоторые фреймворки автоматически разворачивают такие объекты и используют их как обычные поля. В итоге защита не замечает важные данные.

JSON Smuggling

Здесь полезная нагрузка прячется в строке, которая сама по себе является JSON. На первом этапе фильтр проверяет только оболочку. Но приложение делает второй парсинг и получает уже готовый объект:

{ "payload": "{"action":"delete","target":"/users"}" }

После второго разбора это превращается в команду, которую приложение может выполнить. Такой приём описывал Grimminck в статье «JSON Smuggling: A far-fetched intrusion detection evasion technique» ( Medium ). Подробные кейсы с использованием JSON для обхода WAF приводят исследователи Team82 (Claroty), в том числе обход фильтров крупных вендоров ( Claroty , PortSwigger ). Аналогичный обзор есть у Picus Labs .

Примеры сценариев

1. SQL Injection — инъекция спрятана во вложенном объекте, WAF её не видит, а приложение выполняет запрос.
2. XSS — вредоносный код закодирован escape-последовательностями и раскрывается только в браузере.
3. Обход авторизации — повторяющийся ключ role позволяет системе взять нужное злоумышленнику значение.

Почему WAF бессилен

Фильтр работает по шаблонам. Он ищет знакомые конструкции и блокирует их. Но JSON даёт простор для обходов:

• полезная нагрузка прячется глубже во вложенных структурах;
• используются кодировки, которые фильтр не распознаёт;
• дублирующиеся ключи приводят к разным результатам.

Кроме того, WAF не учитывает бизнес-логику конкретного приложения, и поэтому может пропустить действия, которые в реальности нарушают правила.

Как защититься

Есть несколько шагов, которые помогут снизить риски:

1. Использовать один и тот же парсер JSON для фильтра и приложения.
2. Запретить дублирующиеся ключи — включить строгий режим в парсере.
3. Проверять данные после разбора, а не только исходный JSON.
4. Определить структуру через JSON Schema и отклонять всё лишнее.
5. Логировать аномалии вроде экзотических пробелов или повторов полей.

Инструменты для тестирования

Проверить приложение на такие уязвимости можно с помощью:

• Burp Suite — инструмент для перехвата и изменения JSON-запросов.
• Arjun — помогает искать скрытые параметры.
• OWASP Testing Guide — практическое руководство по тестированию безопасности.

Заключение

Обход WAF через JSON строится на деталях: разные трактовки дубликатов, экзотические пробелы, вложенные структуры. Всё это создаёт расхождения между тем, что «видит» фильтр, и тем, как данные обрабатывает приложение. Полностью устранить риск сложно, но строгая валидация, единые парсеры и мониторинг заметно снижают вероятность успешной атаки. Главное — не полагаться только на WAF, а выстраивать многоуровневую защиту.