Аудит сторонних скриптов и SRI
Каждый сторонний скрипт, который загружает ваша страница, выполняется с полными привилегиями вашей страницы: он может читать DOM, наблюдать ввод в формы и действовать внутри сессий ваших посетителей. Этот аудит получает статический HTML страницы, перечисляет каждый внешний скрипт, на который она ссылается, отмечает, какие из них сторонние, какие несут хэш Subresource Integrity (SRI) и какие закреплены за точной версией — а для сторонних скриптов без целостности вычисляет хэш sha384, чтобы вы могли вставить его прямо в тег.
Последнее обновление:
Беспокоитесь, что скрипт поставщика на вашем сайте может измениться или упасть? Следите бесплатно с myeventwatch — оповещения об истечении и простоях, карта не нужна.
Что проверяет этот аудит — и чего он не видит
Проверяющий получает страницу один раз и разбирает HTML, который ему отдали, — только статический HTML. Каждый <script src> в этой разметке перечисляется с его хостом, классифицируется как собственный, когда хост совпадает с регистрируемым доменом вашей страницы, и как сторонний, когда нет, и проверяется на два атрибута, от которых зависит, сможет ли браузер вас защитить: integrity — хэш SRI, который браузер сверяет перед выполнением файла, и crossorigin, который нужен межоригинной проверке SRI, чтобы она работала. Версия в URL тоже оценивается: скрипт, адресованный как [email protected] или /v2.4/, закреплён, а адрес latest или без версии — подвижная цель, чьё содержимое может измениться в любой момент, хотя никто не трогал ваш сайт.
Чётко понимайте границу, потому что она важна: версия 1 разбирает только статический HTML страницы — скрипты, внедрённые во время выполнения JavaScript, не покрываются. Менеджеры тегов, инструменты согласия и виджеты чата обычно создают элементы script из кода после загрузки страницы, и статический разбор их никогда не видит. Относитесь к этому аудиту как к описи того, на что ваши шаблоны и CMS ссылаются напрямую, — обычно это самая большая и самая исправимая часть проблемы, — а контейнеры менеджера тегов проверяйте отдельно, в его собственном предпросмотре и истории изменений. Встроенные скрипты (блоки без src) подсчитываются в результате как факт, потому что они вообще не могут нести SRI; сопутствующее руководство объясняет, что с ними делать.
Столбец хэша: вычислен, а не угадан
Для сторонних скриптов без атрибута integrity проверяющий сам получает скрипт — по тому же защищённому от SSRF пути получения, что и все остальные проверяющие на этом сайте, с лимитом в первые 15 таких скриптов и по 512 КБ каждый, — и вычисляет его хэш SHA-384. Когда получение удаётся, ячейка SRI показывает полный фрагмент, integrity="sha384-…", готовый к вставке в ваш тег рядом с crossorigin="anonymous". Хэш показывается только тогда, когда скрипт действительно был получен. Если получение не удалось, файл оказался слишком большим или скрипт оказался за пределом в 15 штук, ячейка вместо этого показывает эту пометку — никогда не заглушку и не угаданное значение, — а исправление состоит в том, чтобы сгенерировать хэш в вашем собственном сборочном конвейере, где точный файл под рукой.
Связанные проверки: проверка заголовков безопасности оценивает заголовки ответа — включая Content-Security-Policy, естественного партнёра SRI, — оценщик SSL покрывает транспорт, по которому эти скрипты прибывают, а сопутствующая статья сторонние скрипты — это риск цепочки поставок разбирает реальный инцидент, что SRI останавливает, а что нет, и повторяемую процедуру аудита.
Как читать вердикты: сторонний скрипт с целостностью и закреплённой версией — здоровый случай: браузер откажется от подменённого или отредактированного файла. Сторонний скрипт без целостности не является автоматически вредоносным; он незащищён, что означает: его содержимое — это то, что его хост отдаёт сегодня, и вашим единственным предупреждением об изменении будет сам ущерб. Незакреплённые адреса заслуживают того же подозрения, что и отсутствующие хэши, потому что хэш SRI поверх URL latest ломается при первом же обновлении поставщика, — поэтому оба вывода сообщаются рядом и поэтому durable-исправление всегда парное: сначала закрепите точную версию, затем хэшируйте именно этот файл.
Факты, которые показывает эта страница
| Сторонний | Скрипт, чей регистрируемый домен хоста отличается от домена страницы: код, который отдаёт кто-то другой и который выполняется с привилегиями вашей страницы. |
| Целостность (SRI) | Есть ли у тега атрибут integrity: криптографический хэш, который браузер сверяет перед выполнением файла, отказывая при любом несовпадении. |
| Crossorigin | Есть ли у тега атрибут crossorigin, который нужен межоригинной проверке SRI; без него браузеры не могут применить SRI к загрузке. |
| Закреплён | Называет ли URL точную версию ([email protected], /v2.4/), а не плавающий адрес latest или без версии, чьё содержимое может молча меняться. |
| Вычисленный SRI | Для сторонних скриптов без целостности — хэш sha384, который проверяющий вычислил, реально получив файл; показывается только после успешного получения, для первых 15 таких скриптов. |
Часто задаваемые вопросы
Видит ли этот аудит каждый скрипт, который выполняет моя страница?
Нет — и страница говорит об этом прямо: версия 1 разбирает только статический HTML страницы, поэтому скрипты, внедрённые во время выполнения JavaScript, не покрываются. Менеджеры тегов, инструменты A/B-тестирования, баннеры согласия и виджеты чата обычно внедряют скрипты после загрузки; проверяйте их в менеджере тегов или сетевой панелью браузера. Полностью этот аудит покрывает каждый скрипт, на который ваш отдаваемый HTML ссылается напрямую, — именно там живут библиотеки, виджеты CDN и встраиваемый мониторинг.
Откуда берётся хэш в столбце SRI?
Проверяющий сам получает файл скрипта и вычисляет его хэш SHA-384 для сторонних скриптов без атрибута integrity — первых 15, до 512 КБ каждый. Хэш показывается только тогда, когда скрипт действительно был получен: если получение не удалось, файл был слишком большим или лимит был достигнут, ячейка вместо хэша показывает эту пометку. Вставьте фрагмент в ваш тег script вместе с crossorigin="anonymous" и повторяйте аудит после каждого изменения версии: новая версия означает новый хэш.
У скрипта моего менеджера тегов не может быть фиксированного хэша. Что тогда?
Верно: контейнер менеджера тегов спроектирован так, чтобы меняться, поэтому SRI не может его закрепить, и то же верно для любого скрипта, чьё всё назначение — загружать меняющийся код. Для них меры другие: ограничьте, кто может публиковать в контейнер, просматривайте его историю изменений как изменения кода, загружайте его только на страницах, которым он нужен, и используйте Content-Security-Policy, чтобы ограничить, что внедрённые скрипты могут делать и куда могут отправлять данные. SRI защищает фиксированные библиотеки; управление защищает динамические.
Отсутствие атрибута integrity — это чрезвычайная ситуация?
Это постоянная подверженность, а не инцидент. Скрипт почти наверняка является файлом, который поставщик намерен отдавать сегодня; проблема в том, что ничто не остановило бы и не отметило бы другой файл завтра — после компрометации поставщика, угона аккаунта или истёкшего домена. Порядок исправления: сначала скрипты на страницах с входами, платежами или персональными данными, затем закреплённые и хэшированные библиотеки везде остальном, затем длинный хвост. Каждое исправление — однострочное изменение тега, как только версия закреплена.
Почему столбец закрепления называет скрипт «latest» или «без версии»?
Вердикт о закреплении — это эвристическое чтение URL: сегмент, похожий на версию, такой как @1.2.3 или /v2.4/, считается закреплённым; явный сегмент latest считается плавающим; а URL без версии где бы то ни было считается безверсионным. Он помечен как эвристика, потому что только поставщик знает свою схему выпусков, — но смысл для безопасности от метки не зависит: если байты по этому URL могут измениться без изменения URL, хэш SRI не выживет, поэтому сначала закрепляйте, затем хэшируйте.