Как работает межсетевой экран веб-приложений
Межсетевой экран веб-приложений, также известный как web application firewall (WAF), анализирует запросы, которые поступают к сайту или API, и сопоставляет их с правилами безопасности. Он работает на прикладном уровне модели OSI — уровне 7, где доступны данные HTTP: метод запроса, путь, заголовки, параметры, cookies и тело сообщения. В зависимости от настроек WAF регистрирует подозрительные обращения или отклоняет их до передачи приложению.
Проверка может учитывать контекст: например, допустимый формат параметра, тип содержимого и последовательность действий клиента. Правила бывают сигнатурными, то есть распознают известные признаки атаки, и поведенческими — выявляют отклонения от заданного профиля. Для API могут отдельно задаваться допустимые методы, поля и форматы данных, например JSON.
Проверка HTTP- и HTTPS-запросов
В HTTP запрос передаётся без шифрования, поэтому WAF может анализировать его содержимое непосредственно. HTTPS защищает данные TLS-шифрованием. Чтобы проверить путь, заголовки и тело HTTPS-запроса, устройство обычно завершает TLS-соединение и расшифровывает трафик перед передачей приложению. Если WAF не получает расшифрованные данные, проверка содержимого ограничена.
После разбора запроса правила оценивают отдельные элементы и их сочетания. Например, необычные символы в параметре могут быть допустимы в одном поле и подозрительны в другом. Размер тела и способ его разбора также влияют на проверку: слишком крупные или неподдерживаемые форматы могут обрабатываться по отдельным ограничениям.
Отличия WAF от сетевого межсетевого экрана
Сетевой межсетевой экран обычно принимает решения по IP-адресам, портам и сетевым протоколам. Для веб-трафика типичны порты 80 для HTTP и 443 для HTTPS, однако фильтрация по порту сама по себе не показывает, содержит ли запрос вредоносный параметр. WAF анализирует структуру веб-запроса и применяет правила к его содержимому.
Эти средства решают разные задачи и могут использоваться совместно. Сетевой экран ограничивает доступ на уровне соединений, а WAF проверяет запросы, уже направленные к веб-сервису. Ни один из них не заменяет контроль доступа в самом приложении.
Какие угрозы выявляет WAF и где проходят границы защиты
SQL-инъекции, межсайтовый скриптинг и другие атаки на запросы
Правила WAF могут выявлять признаки SQL-инъекций — попыток изменить смысл запроса к базе данных через ввод пользователя. Также обнаруживаются характерные фрагменты межсайтового скриптинга (XSS), при котором вредоносный код пытаются внедрить в данные, отображаемые браузеру. Дополнительные правила применяются к обходу контроля доступа, подозрительным загрузкам файлов, некорректно сформированным запросам и чрезмерной частоте обращений.
Обнаружение зависит от правил и контекста приложения. Кодирование символов, необычный формат данных или новый способ обхода могут затруднить распознавание. Поэтому результат проверки не является доказательством безопасности запроса или приложения.
Уязвимости приложения, которые WAF не устраняет
WAF не исправляет ошибки в исходном коде, настройках базы данных и механизмах авторизации. Он может ограничить часть попыток эксплуатации, но не устраняет причину уязвимости. Если приложение неверно проверяет права пользователя, использует устаревшую библиотеку или раскрывает данные через ошибку логики, одного фильтра трафика недостаточно.
Защита также зависит от того, видит ли WAF нужный трафик и корректно ли разбирает его формат. Обновление приложения, тестирование кода и устранение обнаруженных уязвимостей остаются отдельными задачами.
Размещение и режимы работы WAF
Варианты включения в путь трафика
WAF размещают перед приложением как обратный прокси, включают в сетевой путь между клиентом и сервером либо используют на уровне инфраструктуры, где проходит входящий веб-трафик. В прокси-схеме запрос сначала поступает к WAF, проходит проверку и затем передаётся приложению. Если устройство работает вне основного пути передачи, оно может наблюдать копию трафика, но не всегда способно остановить запрос.
Выбор схемы определяет, где завершается TLS-соединение, как сохраняются адреса клиентов и что происходит при недоступности WAF. При изменении маршрута требуется проверить, что запросы к приложению не обходят фильтр и что служебные заголовки не подменяются внешним источником.
Обнаружение и блокировка запросов
В режиме обнаружения WAF записывает срабатывания, но пропускает запросы. Такой режим помогает выяснить, какие правила затрагивают обычную работу сайта или API. В режиме блокировки запрос, нарушивший правило, отклоняется; часто клиент получает ответ с кодом HTTP 403. Перевод правил в блокировку без предварительной проверки может прервать допустимые операции.
Настройка правил и разбор срабатываний
Ложные срабатывания и настройка исключений
Ложное срабатывание возникает, когда разрешённый запрос совпадает с признаком атаки. Например, строка с SQL-синтаксисом может быть частью поискового запроса или пользовательского текста. Для диагностики сопоставляют сработавшее правило, поле запроса, адрес обработчика и ожидаемое поведение приложения. Исключение настраивают узко — для конкретного правила, параметра или маршрута, а не для всего трафика.
Журналы событий и проверка правил после изменений
Журнал WAF может содержать время события, идентификатор правила, адрес запроса, действие фильтра и доступные сведения о клиенте. Эти данные помогают связать блокировку с обращением к приложению и отличить повторяющуюся атаку от ошибки настройки. Секреты, токены и персональные данные следует маскировать в журналах, если они попадают в поля запросов.
Изменение формы, маршрутов, API или формата данных способно повлиять на срабатывания прежних правил. После обновления проверяют типовые сценарии приложения, анализируют события в режиме обнаружения и тестируют исключения. Правила пересматривают и при появлении новых признаков атак: настройки фильтра должны соответствовать фактическому поведению приложения.
