WAAP видит запрос. Сторонние скрипты, работающие в браузере, в основном ему невидимы.
Современные веб-страницы создаются не только из собственного JavaScript организации. Платёжные страницы, инструменты аналитики, чат-виджеты, системы A/B-тестирования, рекламные теги и платёжные SDK могут загружать несколько сторонних скриптов. Если хотя бы один из таких скриптов будет скомпрометирован, вредоносный код в браузере пользователя сможет полностью обойти классические средства управления WAAP на уровне запросов.
В платёжных потоках в особенности риск на стороне клиента — это уже не просто вопрос передовых практик. PCI DSS 4.0 v4.0.1 сделал контроль, инвентаризацию и целостность скриптов, работающих на платёжных страницах, более заметными. Организации должны быть в состоянии продемонстрировать, каким источникам разрешено выполняться на каких страницах.
Требовать от команд разработчиков вручную добавлять заголовки CSP, HSTS, защиты от фрейминга и политики referer к каждой странице неустойчиво. Изменение кода затруднено в устаревших приложениях; в современных приложениях разные сервисные команды могут непоследовательно применять один и тот же стандарт безопасности. В результате заголовки безопасности присутствуют на одних страницах и отсутствуют на других.
Правильный подход — применять заголовки безопасности браузера централизованно, независимо от кода приложения и с позиции, управляемой политиками. ADC должен перезаписывать заголовки ответов для стандартизации CSP, HSTS, защиты от clickjacking, предотвращения MIME-sniffing, управления referer и очистки fingerprint.
TR7 Защита клиентских скриптов реализует эту модель: применяет базовые заголовки безопасности для рисков на стороне клиента на уровне vService и связывает безопасность браузера с центральной политикой WAAP.
Наш подход
TR7 реализует защиту клиентских скриптов через перезапись заголовков ответов, профиль CSP, очистку fingerprint и видимость соответствия.
Заголовки ответов централизованно применяются на уровне ADC
TR7 применяет заголовки безопасности на этапе HTTP-ответа с использованием поведения set-header или add-header. Средства управления безопасностью браузера могут быть активированы без изменения кода приложения или структуры сертификатов.
Поведение CSP становится частью политики vService
Заголовок Content-Security-Policy передаёт браузеру разрешённую модель источников. TR7 в настоящее время обеспечивает базовую защиту CSP через фиксированный подход `default-src 'self';`.
Очистка server fingerprint скрывает технологическую информацию
Такие заголовки, как Server, X-Powered-By, X-AspNet-Version и X-AspNetMvc-Version, могут быть удалены из ответов. Это затрудняет злоумышленнику формирование инвентаря технологий и сопоставление CVE.
Видимость соответствия PCI поддерживается через заголовки безопасности
vService с активным правилом securityHeaders могут быть представлены в качестве свидетельств в отчётах о соответствии. Это укрепляет аудиторский след для обеспечения безопасности платёжных страниц и процессов управления клиентскими средствами контроля.
Возможности
Защита клиентских скриптов применяет 8 готовых заголовков безопасности в рамках единого правила securityHeaders.
Заголовок Content-Security-Policy передаёт браузеру разрешённую модель источников
TR7 может добавлять заголовок Content-Security-Policy через правило securityHeaders. Текущее поведение создаёт базовую политику безопасности с `default-src 'self';`. Эта политика нацелена на браузерное поведение по умолчанию, принимающее только ресурсы из того же источника. Более сложные требования CSP следует решать через пользовательскую конфигурацию заголовков или изменения на стороне приложения.
Целостность скриптов анализируется на устройстве — телеметрия не покидает периметр
Скрипты, работающие на платёжной или иной чувствительной странице, инвентаризуются, их целостность отслеживается, и изменение не обнаруживается задним числом, а сообщается. Именно эту меру PCI DSS v4.0.1 делает обязательной в пунктах 6.4.3 и 11.6.1. Анализ выполняется на вашем собственном устройстве: для закрытой сети или организации с требованиями к резидентности данных ни содержимое страниц, ни клиентская телеметрия не отправляются в облако вендора.
HSTS enforcement усиливает поведение HTTPS на уровне браузера
Заголовок Strict-Transport-Security может применяться на TLS-соединениях. Он инструктирует браузер требовать HTTPS для соответствующего домена. Такие параметры, как includeSubDomains и preload, обеспечивают более строгое поведение безопасности. HSTS применяется только в контексте TLS, чтобы предотвратить выдачу некорректной политики для HTTP-only хостов.
X-Frame-Options SAMEORIGIN снижает риск clickjacking
Заголовок X-Frame-Options может применяться со значением SAMEORIGIN. Это ограничивает загрузку страницы внутри iframe на другом источнике. Помогает снизить риск clickjacking в особенности на страницах входа, оплаты, административных панелях и страницах чувствительных транзакций. Обеспечивает низкозатратную базовую защиту от атак подмены пользовательского интерфейса.
X-Content-Type-Options nosniff ограничивает атаки MIME confusion
Заголовок X-Content-Type-Options может быть добавлен со значением nosniff. Это помогает предотвратить угадывание браузером типа контента и его выполнение в неожиданном формате. Средство управления особенно ценно для потоков загрузки файлов, статического контента и устаревших приложений, возвращающих неправильные типы контента. Риск на стороне клиента от MIME confusion снижается.
Referrer-Policy снижает утечку конфиденциальной URL-информации
Заголовок Referrer-Policy может применяться со стандартным значением no-referrer-when-downgrade. Это ограничивает утечку referer в таких сценариях, как переходы с HTTPS на HTTP. Поведение referer важно для URL-адресов, содержащих параметры граждан, клиентов или сессий. Организации могут централизованно ограничить объём информации об исходном URL, который браузер передаёт на внешние сайты.
Permission-Policy переводит разрешения браузера в позицию запрета по умолчанию
Заголовок Permission-Policy может использоваться для ограничения доступа к возможностям браузера, таким как микрофон, камера, геолокация и аналогичные API. TR7 применяет этот заголовок в рамках правила securityHeaders для уменьшения ненужной поверхности разрешений браузера. На портальных, платёжных и административных экранах это предотвращает доступ страниц к неожиданным API. Безопасность на стороне клиента не ограничивается только источником скрипта.
X-XSS-Protection обеспечивает дополнительный уровень для старых браузеров
Хотя заголовок X-XSS-Protection имеет ограниченный эффект в современных браузерах, он может использоваться для совместимости со старыми клиентами. Поведение `1; mode=block` активирует базовый XSS-фильтр в некоторых устаревших браузерах. Этот заголовок сам по себе не является гарантией безопасности и должен рассматриваться совместно со средствами управления CSP и WAAP. Предоставляет низкозатратный дополнительный уровень для организаций с устаревшей базой пользователей.
Очистка server fingerprint снижает риск перечисления технологий
TR7 может удалять такие заголовки, как Server, X-Powered-By, X-AspNet-Version и X-AspNetMvc-Version. Эти заголовки могут указывать на используемые сервер приложений, фреймворк или версию среды выполнения. Злоумышленники могут использовать эту информацию для сопоставления CVE и целевых попыток эксплуатации. Очистка fingerprint — практический шаг по усилению защиты, уменьшающий видимую поверхность атаки.
Применение политики для каждого сервиса обеспечивает разное поведение по пути или домену
securityHeaders может быть привязан как тип правила к конкретным условиям vService, домена или пути. Платёжная страница может работать с более строгим набором, внутренний портал — с другим, а устаревшее приложение — с более разрешительной комбинацией. Это предотвращает поломку приложений единой глобальной политикой заголовков. Операторы применяют заголовки безопасности в соответствии с контекстом сервиса.
Дополнительный клиентский агент не требуется — работает на уровне заголовков ответа
TR7 реализует текущий объём защиты клиентских скриптов на уровне заголовков ответа. Дополнительный JavaScript-агент, клиентский SDK или отдельный reverse proxy не нужны. Этот подход обеспечивает низкую задержку и широкую совместимость. Фактическая текущая возможность — стандартизация заголовков безопасности; никаких заявлений о обнаружении skimmer в режиме реального времени или автоматическом внедрении SRI не делается.
Свидетельства заголовков безопасности могут быть связаны с отчётностью PCI
vService с активным правилом securityHeaders могут быть представлены в отчётах о соответствии. Это упрощает информирование аудиторов о том, где именно применяются заголовки безопасности платёжных страниц. Поддерживает создание технических свидетельств для ожиданий по безопасности на стороне клиента в рамках PCI DSS 4.0 v4.0.1. Отчётность делает видимым не только то, что политика заголовков настроена, но и на каких сервисах она активна.
Заголовки безопасности могут сохраняться на пользовательских HTML-ответах
Когда возвращаются пользовательские HTML-страницы — например, для bot protection или блокировки доступа — заголовки безопасности могут поддерживаться на том же пути ответа. Это предотвращает возврат страниц с ошибками или challenge со слабыми заголовками безопасности по сравнению с основным приложением. Каждый ответ, представляемый пользователю, приближается к тому же базовому стандарту безопасности браузера. Последовательность особенно важна в потоках входа и верификации ботов.
Операционная глубина
Защита клиентских скриптов работает с учётом порядка заголовков ответа, условия HSTS, фиксированного поведения CSP, типа правила securityHeaders и очистки fingerprint.
Порядок применения заголовков
TR7 может переопределять некоторые заголовки с помощью set-header и добавлять другие с помощью add-header. Это различие определяет поведение существующих заголовков приложения. Перед переходом в production стоит проверить, не конфликтуют ли собственные заголовки приложения с добавляемыми TR7.
Условие HSTS
HSTS должен применяться только на TLS-соединениях. TR7 связывает этот заголовок с условием ssl_fc, чтобы HTTP-only хосты не получали ложный заголовок HSTS. Некорректная политика HSTS может вызвать проблемы с доступом на некоторых доменах, поэтому использовать её следует с осторожностью.
Фиксированное поведение CSP
Когда CSP включён в текущем поведении securityHeaders, заголовок `default-src 'self';` создаётся как фиксированное значение. В активных возможностях этой страницы нет дополнительного редактора пользовательских директив. Для более детальных требований к CSP следует планировать пользовательское правило заголовка или конфигурацию на стороне приложения.
Взаимосвязь типа правила и оценки
securityHeaders не работает как правило оценки WAAP-сигнатур. Оно рассматривается как правило усиления заголовков ответа, которое применяется всегда. Следовательно, оно не привязано к оценке атаки или пороговому результату.
Область очистки fingerprint
Заголовки Server, X-Powered-By, X-AspNet-Version и X-AspNetMvc-Version могут быть удалены. Удаление этих заголовков не меняет поведение приложения; оно только снижает внешнюю видимость технологической информации. В устаревших приложениях этот простой шаг может существенно снизить утечку информации.
Тестирование на поломку приложения
Политики CSP и фреймирования могут влиять на некоторые компоненты приложения. Страницы, использующие встроенные скрипты или загружающие контент из внешних источников, следует предварительно проверить в тестовой среде. Подход TR7, основанный на правилах, упрощает опробование строгой политики на ограниченном пути или домене перед широким внедрением.
Когда это использовать
Свидетельства заголовков PCI в платёжных потоках e-commerce
Команды e-commerce могут включать CSP, HSTS и очистку server fingerprint на уровне vService для страниц оформления заказа. Эта конфигурация создаёт отчётные технические свидетельства для средств управления безопасностью на стороне клиента PCI DSS 4.0 v4.0.1.
Сокращение поверхности iframe и разрешений на банковских порталах
Банковские порталы могут использовать X-Frame-Options SAMEORIGIN и Permission-Policy для ограничения несанкционированного встраивания в iframe и ненужного доступа к API браузера. Поверхность атаки на стороне клиента на страницах входа и транзакций сужается.
Снижение утечки referer в государственных приложениях
Приложения государственного сектора могут применять Referrer-Policy на страницах с конфиденциальной URL-информацией. Это снижает риск передачи на внешние сайты фрагментов URL, связанных с сессиями граждан или контекстом транзакций.
Скрытие технологической информации в устаревших приложениях
В старых приложениях на .NET или аналогичных платформах заголовки Server, X-Powered-By и версии фреймворков могут утекать наружу. TR7 удаляет эти заголовки, затрудняя злоумышленнику формирование инвентаря технологий.
Политика заголовков на уровне тенанта в мультитенантном SaaS
Провайдеры SaaS могут применять разные комбинации securityHeaders для каждого vService тенанта. B2B-тенанты могут работать с более разрешительной политикой там, где это допускают требования соответствия; B2C-потоки могут использовать более строгий набор заголовков.
Часто задаваемые вопросы
Все 8 заголовков безопасности активируются одновременно?
HSTS применяется ко всем хостам?
Можно ли настроить заголовок CSP?
Требует ли эта защита дополнительного JavaScript-агента или кода на стороне клиента?
Достаточно ли этого для соответствия PCI DSS 4.0 v4.0.1?
Сохраняются ли заголовки безопасности на пользовательских страницах с ошибками, например страницах bot protection?
Стандартизируйте заголовки безопасности браузера на уровне ADC
CSP, HSTS, защита от clickjacking и очистка server fingerprint — из единой политики, без изменения кода приложения. Давайте пройдём живую настройку на ваших собственных сервисах.