Как работает WAF
В этом посте я хотел бы раскрыть такую тему, как работа WAF (Web Application Firewall).
WAF — это файрвол веб-приложений, который используется как наложенное средство защиты. Это значит, что он располагается перед основным веб-приложением и анализирует входящий и исходящий трафик. В режиме реального времени он принимает решение: пропустить запрос дальше или отклонить его.
▻ Брандмауэры (firewalls / файрволы) — это, по сути, современная реализация средневекового принципа защиты: сначала поставить рубеж, а уже потом разбираться, кто и зачем пытается пройти внутрь.
Если для вас сети — пока ещё чуждая тема, то советую почитать**«Компьютерные сети» Таненбаума**. По моему мнению, это уже классика для IT-сферы, и когда-то лично для меня эта книга открыла дверь в ИБ. ➥ Компьютерные сети. 6-е издание
У WAF есть разные варианты анализа трафика, а именно: • Сигнатурный анализ (Signature-based) • Эвристический / семантический анализ (Heuristic / Semantic) • Анализ поведения (Behavioral / Anomaly-based) • Контекстный анализ / прокси-модель (Proxy-based / Positive Security Model) • «Иммунные» WAF (RASP — Runtime Application Self-Protection) • Анализ на основе API-спецификаций (API Security / Schema Validation)
━Сигнатурный анализ (Signature-based)━
Это основа большинства классических WAF, таких как ModSecurity или старые версии Imperva. Анализ идёт по принципу сигнатур и регулярных выражений.
• Такой WAF сравнивает запрос с базой известных атак. Увидел union select 1,2,3 — заблокировал. Это самый понятный и базовый подход, но его легко обходят, если атакующий меняет форму полезной нагрузки.
━Эвристический / семантический анализ━
Здесь WAF пытается понять не просто строку, а уже саму структуру языка: SQL, JavaScript, HTML. Анализ может идти через парсинг и построение AST (Abstract Syntax Tree)
• WAF разбирает запрос на токены. Если в параметре, где ожидается число, он видит SQL-конструкцию с высоким уровнем опасности, например сочетание SELECT, FROM и information_schema, то срабатывает правило.
То есть здесь логика уже не “нашёл конкретную строку”, а “увидел опасную конструкцию”.
━Анализ поведения━
Этот подход строится на машинном обучении (ML) и базовой статистике. Задача — сформировать профиль “нормального” трафика.
• WAF учится на легитимных запросах. Если пользователь обычно отправляет 10 параметров, а потом внезапно отправляет 100 — это аномалия. Если в поле имени вдруг появляется шелл-код — это тоже аномалия.
Такой подход хорошо ловит нетипичное поведение, но иногда даёт ложные срабатывания.
━Контекстный анализ / прокси-модель━
Здесь используется модель разрешённого поведения (allow-list). Это один из самых надёжных, но и самых сложных в настройке видов анализа. Часто встречается в Next-Gen WAF, например в Cloudflare, AWS WAF с Custom Rules, F5 ASM.
• Сначала WAF изучает приложение и понимает его структуру: поле age — это целое число от 1 до 120; поле name — это [a-zA-Z ]; структура JSON фиксирована.
Блокируется всё, что не соответствует ожидаемой модели Это уже не “ищем зло”, а “пропускаем только то, что заранее считаем нормой”.
━━━━ «Иммунные» WAF ━━━━
Это агент, который находится внутри рантайма приложения (JVM, .NET, PHP), а не перед ним. Лично я бы уже не называл это классическим WAF, но упомянуть такой подход точно стоит
• Он смотрит не только на HTTP-запрос, а на то, что происходит внутри самого приложения. Если запрос ?id=1’ в итоге пытается привести к вызову mysql_query, то RASP видит это и может заблокировать выполнение прямо в момент вызова функции.
То есть защита срабатывает уже ближе к самой бизнес-логике.
━Анализ на основе API-спецификаций━
Это отдельный вид защиты для API: GraphQL, REST, gRPC. Он анализирует соответствие запросов OpenAPI (Swagger) или GraphQL-схеме
• Такой WAF знает точную схему API. Если в GraphQL-запросе запрашивается поле __typename, выполняется интроспекция или приходит поле, которого вообще нет в схеме, запрос может быть заблокирован.
