Истёкший домен CDN получил нового владельца и остался в коде тысяч сайтов
В июле 2025 года неизвестный зарегистрировал домен закрытой сети доставки контента, срок регистрации которого истёк несколько лет назад. Тысячи сайтов, репозиториев и страниц документации всё ещё содержат жёстко заданные обращения к его поддоменам, а новый владелец получил контроль над wildcard DNS для всей зоны.
Корневой домен сейчас ведёт на перегруженную рекламой страницу загрузчика медиа. Однако существеннее другое: владелец зоны может решать, какой ответ получат браузеры при запросах к прежним CDN-хостам. Авторы таких сайтов не обязательно увидят сбой и могут не узнать о смене контроля над доменом.
Сторонний скрипт не попадает в обычную проверку сборки
Сценарий напоминает случай с polyfill.io. В июне 2024 года домен сервиса JavaScript-полифиллов, встроенного более чем в 110 тысяч сайтов, сменил владельца и начал отдавать условные перенаправления мобильным посетителям. Сами сайты не были взломаны: когда-то в их код добавили внешний тег script и затем не пересматривали это решение.
Статический анализ, сканирование зависимостей и SCA проверяют то, что организация собирает и поставляет. Внешний скрипт загружает браузер пользователя с сервера, который компания не администрирует. Ответ может различаться в зависимости от страны, user agent, реферера, времени или сессии, поэтому единичная проверка не гарантирует, что реальным посетителям выдаётся тот же код.
Такой скрипт работает с теми же правами, что и собственный JavaScript страницы: может читать DOM, поля формы по мере ввода, cookie и local storage, а также отправлять запросы на внешние адреса. Для атак класса Magecart достаточно, чтобы разрешённый сторонний ресурс начал вести себя иначе; компрометация сервера сайта для этого не требуется.
CSP позволяет увидеть код в браузере пользователя
Content Security Policy обычно связывают с защитой от межсайтового выполнения сценариев. Но политика также задаёт разрешённые источники кода, блокирует неразрешённые и формирует сообщения о нарушениях. Эти сигналы приходят из реальных браузерных сессий, поэтому могут отразить поведение, зависящее от географии, устройства или статуса входа.
В сентябре 2026 года Report URI по таким отчётам выявила группу скомпрометированных интернет-магазинов с кампанией ClickFix. После компрометации административного доступа в CMS размещались Base64-загрузчики: через редиректор они показывали ложную проверку «подтвердите, что вы человек», копировали PowerShell-команду в буфер обмена и создавали задачу для закрепления. Часть управляющих доменов уже встречалась в сообщениях браузеров, хотя репутационные сервисы ещё считали их чистыми.
Как начать без риска для работающего сайта
Заголовок Content-Security-Policy-Report-Only не применяет ограничений и не меняет поведение страницы: он только сообщает, что было бы заблокировано действующей политикой. Это позволяет сначала собрать наблюдения, составить инвентарь внешних скриптов, а затем отслеживать и согласовывать изменения.
Для сайтов с приёмом карт требования PCI DSS v4.0.1 6.4.3 и 11.6.1 стали обязательными 31 марта 2025 года. Они требуют авторизовать каждый скрипт на платёжной странице, обеспечивать его целостность, вести инвентарь с деловым обоснованием и обнаруживать несанкционированные изменения содержимого страницы и HTTP-заголовков.
Практический вывод для бизнеса: стоит инвентаризировать все внешние домены и скрипты, которые вызывают страницы, начать сбор CSP-отчётов в режиме Report-Only и установить процесс проверки изменений. Это помогает заметить не только уязвимость собственного кода, но и смену поведения ресурсов, которыми организация больше не управляет.