Основные выводы

Сторонний JavaScript выполняется вне средств управления серверного WAF, подвергая приложения рискам сбора данных на стороне клиента и внедрения скриптов.

Платформа Akamai Application Protection Platform теперь объединяет правила для браузерной стороны и политики защиты веб-приложений и API (WAAP) на стороне сервера в единой консоли управления.

Телеметрия клиентских угроз поступает напрямую в Web Security Analytics (WSA) для упорядоченного межслойного расследования инцидентов.

JavaScript работает практически в каждом современном веб-приложении. Он обеспечивает работу интеграций, динамического контента, платежных сценариев и функций пользовательского интерфейса. Он также выполняется в браузере — за пределами средств серверного контроля, которые традиционно администрируют команды безопасности приложений.

Это создает пробел, который злоумышленники умеют использовать. Внедрение скриптов, экфильтрация данных форм и сбор учетных данных происходят на стороне клиента в пространстве, недоступном для стандартных средств WAF и защиты API. Исторически защита от этого требовала отдельного продукта безопасности, отдельной конфигурации и отдельного рабочего процесса расследования.

Мы это изменили.

Определяйте правила для клиентской стороны там же, где вы настраиваете всё остальное

Платформа Akamai Application Protection Platform теперь включает встроенную защиту на стороне клиента. Команды безопасности могут создавать клиентские правила непосредственно в политиках безопасности защиты приложений: там же, где они настраивают правила WAF, защиту от ботов и средства защиты API.

Это не отдельная консоль или надстройка; это выделенный раздел в рамках существующего интерфейса политик, созданный по тем же принципам.

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

Контролируйте доступ скриптов

Браузер предоставляет JavaScript доступ к критически важным элементам: полям конфиденциальных форм, сетевым назначениям, файлам cookie, локальному хранилищу и хранилищу сеансов. Неправильно настроенный или скомпрометированный скрипт может получить доступ к любому из них.

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

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

Расследуйте нарушения там же, где вы уже исследуете угрозы

Когда правило клиентской стороны срабатывает, нарушение попадает в Web Security Analytics (WSA). В дополнение к серверным данным, уже представленным в WSA, вы видите:

Сработавшее правило

Сработавшее правило

Задействованный скрипт

Задействованный скрипт

Тип активности

Тип активности

Метод JavaScript

Метод JavaScript

Соответствующий селектор

Соответствующий селектор

Релевантные контекстные данные

Релевантные контекстные данные

Специально созданное клиентское представление выводит эту активность в разрезе правил, скриптов, имен хостов, путей, типов браузеров и географических регионов. Вам не нужно изучать новый инструмент расследования. Данные хранятся в WSA, где уже происходит остальной процесс расследования угроз вашим приложениям.

Видимость клиентских скриптов и современные ИИ-приложения

Поскольку предприятия внедряют клиентские ИИ-ассистенты, сторонние чат-виджеты на основе LLM и браузерные скрипты вывода в свои веб-приложения, подверженность рискам на стороне клиента резко возрастает. Вредоносные скрипты могут перехватывать локальный ввод промптов или полезные данные ответов ИИ прямо в браузере. Расширяя платформу Akamai Application Protection Platform на клиентскую сторону, команды AppSec получают унифицированный обзор как традиционных зависимостей JavaScript, так и новых путей клиентских данных ИИ.

Единая модель политик для всей поверхности атаки приложения

Угрозы на стороне браузера и на стороне сервера затрагивают одно и то же приложение. Их расследование в одном месте и в рамках единой модели политик меняет подходы к работе команд безопасности.

Архитекторы безопасности могут включать средства контроля клиентской стороны в ту же политику, которую они используют для остальной части своей системы защиты приложений. Инженеры по безопасности приложений могут расследовать клиентские нарушения без переключения на отдельный продукт. Аналитики SOC, реагирующие на инцидент, могут видеть поведение на стороне клиента в том же представлении, которое они уже используют.

Практическая ценность платформенного подхода заключается не в новизне какой-то отдельной функции, а в том, что защита больше не фрагментирована.

Об авторе (-ах)

Борис Кирзнер

Борис Кирзнер — старший менеджер по продукту в Akamai, отвечающий за продуктовую концепцию, стратегию и операции в сфере продуктов для клиентской защиты. Он обладает солидным опытом в области архитектурного проектирования, разработки программного обеспечения и безопасности, насчитывающим более 20 лет работы над созданием облачных продуктов безопасности от зарождения до запуска, включая защиту веб-приложений, управление ботами и защиту на стороне клиента. Борис имеет степень магистра инженерных наук в области информационных систем и степень бакалавра наук в области компьютерных наук Техниона — Израильского технологического института.