Продолжение практикума по веб-защите

CSP на практике: хеши, загрузчики и встраивание страниц

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

Практика → проверка решения164 минуты10 модулей20 вопросов
После курса

Что вы сможете сделать

  1. Выбирать точный вход хеширования и отличать допуск кода от его безопасности.
  2. Находить действующую директиву без сложения несовместимых разрешений.
  3. Проверять источник адресов зависимостей при strict-dynamic и целостность внешнего скрипта отдельно от его метаданных.
  4. Проверять всю цепочку встраивания страницы и её связь с заголовком X-Frame-Options.
Модуль 1 из 10

Какой текст попадает в хеш?

Работаем с алгоритмом проекта CSP Level 3 от 13 августа 2026 года. Сначала устанавливаем вход сравнения, затем выбираем разрешённый алгоритм и представление результата.

  • hash-source допускает SHA-256, SHA-384 и SHA-512. Запись ожидаемого хеша даёт один путь допуска кода, а не полную оценку безопасности страницы.

    Проверить тезис: Разрешение кода по хешу CSP 01

  • Для встроенного скрипта берётся текст программы после обработки HTML и кодирования UTF-8. Окружающие теги не входят в этот вход; значимые пробелы и переводы строк сохраняются.

    Проверить тезис: Разрешение кода по хешу CSP 02

  • В алгоритме хеша встроенного кода символ «-» заменяется на «+», а «_» на «/». Nonce сравнивается как строка и не получает этого преобразования.

    Проверить тезис: Разрешение кода по хешу CSP 03

Модуль 2 из 10

Что означает совпавший хеш?

Разделяем допуск кода политикой и оценку самого кода. Особое внимание — сочетанию хешей с общим разрешением встроенного содержимого.

  • Nonce или хеш в эффективном списке отменяет общий допуск unsafe-inline этого списка. Совпадающий элемент при этом может быть разрешён собственным nonce или хешем.

    Проверить тезис: Разрешение кода по хешу CSP 04

  • Совпадение хеша не проверяет безопасность программы и не очищает недоверенный HTML. CSP дополняет контекстное кодирование и исправление точки внедрения, а не заменяет их.

    Проверить тезис: Разрешение кода по хешу CSP 05 · Политика безопасности содержимого (CSP) 02

Модуль 3 из 10

Какая директива принимает решение?

Назовите вид проверки до чтения списка разрешений. Специальный запрет и отсутствие специальной директивы — разные состояния.

  • script-src-elem применяется к запросам и блокам скриптов, script-src-attr — к обработчикам событий в атрибутах.

    Проверить тезис: Директивы CSP для скриптов 01

  • При отсутствии специальной директивы переходят к script-src, затем к default-src. Это упорядоченный выбор внутри одной политики, а не объединение списков.

    Проверить тезис: Директивы CSP для скриптов 02

  • Присутствующая script-src-attr заменяет общую script-src для обработчиков. Специальный запрет не отменяется общим разрешением unsafe-inline.

    Проверить тезис: Директивы CSP для скриптов 03

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

    Проверить тезис: Директивы CSP для скриптов 05

  • script-src-elem не управляет проверками unsafe-eval и не служит запасной для worker-src. Разрешение обычного скрипта не описывает весь JavaScript.

    Проверить тезис: Директивы CSP для скриптов 04

Модуль 4 из 10

Кому передаётся решение о зависимостях?

strict-dynamic меняет значение списка узлов для скриптов. Проверяем не только исходный nonce, но и код, который выбирает дальнейшие адреса.

  • Допущенный по nonce или хешу загрузчик может создавать зависимости вне HTML-парсера без перечисления каждого узла в политике.

    Проверить тезис: Динамическое доверие CSP 01

  • В этой ветви загрузки скриптов strict-dynamic не использует узлы, схемы, self и unsafe-inline как прежние разрешения. Адрес CDN рядом с ним не ограничивает программно созданные зависимости.

    Проверить тезис: Динамическое доверие CSP 02

  • document.createElement создаёт элемент вне парсера; document.write вставляет через парсер. Второму способу без собственного допуска не достаётся то же разрешение.

    Проверить тезис: Динамическое доверие CSP 03

  • Если злоумышленник управляет адресом программно создаваемого скрипта, правильно разрешённый загрузчик может загрузить нежелательную программу.

    Проверить тезис: Динамическое доверие CSP 04

  • Для вставленного парсером запроса без совпавшего nonce или подходящих данных целостности ветка strict-dynamic запрещает загрузку; один адрес узла в списке не помогает.

    Проверить тезис: Динамическое доверие CSP 05

Модуль 5 из 10

Разрешён ли текст или доказан желаемый запуск?

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

  • unsafe-hashes расширяет сопоставление хеша на обработчики и другие названные алгоритмом встроенные контексты. Обычный хеш script сам этого не делает.

    Проверить тезис: Хеши обработчиков событий CSP 01

  • Nonce применяется к элементам script и style, а не к обработчикам в атрибутах. Nonce на кнопке не создаёт такой допуск.

    Проверить тезис: Хеши обработчиков событий CSP 02

  • Хешируется текст обработчика, например вызов функции, а не целый HTML-элемент. Изменённый текст требует новой проверки соответствия.

    Проверить тезис: Хеши обработчиков событий CSP 03

  • Совпавший текст не связан автоматически с желаемым событием. При допускающей политике чувствительный вызов может быть перенесён в другой контекст исполнения.

    Проверить тезис: Хеши обработчиков событий CSP 04

  • Пояснение CSP рекомендует избегать unsafe-hashes в новых страницах. Допуск старого обработчика не делает его безопасной точкой для непроверенных данных.

    Проверить тезис: Хеши обработчиков событий CSP 05

Модуль 6 из 10

Достаточно ли одного совпавшего хеша внешнего файла?

Ограничиваем задачу допуском именно по hash-source. Другие разрешающие ветви, такие как подходящий nonce, в примерах исключены.

  • CSP сначала сопоставляет метаданные integrity с политикой. Проверку полученных байтов выполняет механизм целостности ресурса отдельно.

    Проверить тезис: Хеш внешнего скрипта в CSP 01

  • Каждый распознанный хеш integrity должен присутствовать среди разрешённых; набор должен быть непустым. Один неразрешённый распознанный хеш даёт отказ всей этой ветви.

    Проверить тезис: Хеш внешнего скрипта в CSP 02

  • При отсутствии или пустом разборе integrity ветка хешей не совпадает, даже когда ожидаемый хеш есть в заголовке.

    Проверить тезис: Хеш внешнего скрипта в CSP 03

  • Нераспознанные значения не участвуют в сравнении. Однако только невалидные записи не создают требуемого непустого набора.

    Проверить тезис: Хеш внешнего скрипта в CSP 04

  • У встроенного и внешнего варианта визуально того же кода может различаться вход хеширования. Хеш нельзя переносить без проверки представления байтов.

    Проверить тезис: Хеш внешнего скрипта в CSP 05

Модуль 7 из 10

Кто встраивает страницу и где должна быть политика?

Не смешиваем загрузку дочерних страниц с ограничением внешних контейнеров защищаемого документа.

  • frame-ancestors ограничивает предков, которые встраивают ресурс. Разрешения на собственные дочерние страницы задаются в другом направлении.

    Проверить тезис: Допустимые предки страницы CSP 01

  • Для frame-ancestors нет подстановки default-src. Общий запрет загрузок не становится запретом внешнего встраивания.

    Проверить тезис: Допустимые предки страницы CSP 03 · Политика безопасности содержимого (CSP) 05

  • frame-ancestors в meta игнорируется. Для этой директивы проверяем политику, доставленную с HTTP-ответом.

    Проверить тезис: Допустимые предки страницы CSP 04

Модуль 8 из 10

Достаточно ли разрешить непосредственный контейнер?

Проверяем цепочку вложения целиком и условие взаимодействия CSP с X-Frame-Options в модели документа.

  • Алгоритм проверяет каждого предка. Если непосредственный родитель разрешён, но внешний контейнер не совпадает с политикой, проверка даёт запрет.

    Проверить тезис: Допустимые предки страницы CSP 02

  • Значения 'none' и 'self' примерно соответствуют DENY и SAMEORIGIN. Наличие frame-ancestors в блокирующей политике заставляет модель игнорировать X-Frame-Options; режим только отчётов не выполняет это условие.

    Проверить тезис: Допустимые предки страницы CSP 05

Модуль 9 из 10

Какая политика действительно остановила действие?

Результат одной директивы не описывает весь набор ограничений. Отделяем блокирующие политики от наблюдения.

  • CSP задаёт правила загрузки и исполнения содержимого; для конкретного действия нужно определить применимые директивы.

    Проверить тезис: Политика безопасности содержимого (CSP) 01

  • Content-Security-Policy-Report-Only наблюдает нарушения, но сама эта политика не блокирует действие.

    Проверить тезис: Политика безопасности содержимого (CSP) 03

  • Действие должно удовлетворять каждой блокирующей политике. Более широкое разрешение во второй не отменяет запрет первой.

    Проверить тезис: Политика безопасности содержимого (CSP) 04

Модуль 10 из 10

Что остаётся проверить после совпадения nonce?

Завершаем практику точными границами уже принятого механизма nonce. Длина значения, число элементов и доверие к разметке проверяются отдельно.

  • Браузер сопоставляет значение элемента с nonce-source политики. Это проверка допуска, а не анализ безопасности самого кода.

    Проверить тезис: Одноразовое значение CSP (nonce) 01

  • Новое значение создают для каждого ответа и выдают только разрешённым элементам.

    Проверить тезис: Одноразовое значение CSP (nonce) 02

  • Рекомендация — не менее 128 бит случайности до кодирования. Количество печатных символов не равно числу случайных битов.

    Проверить тезис: Одноразовое значение CSP (nonce) 03

  • Одно значение ответа может разрешать несколько подготовленных элементов. Оно не расходуется после первого скрипта.

    Проверить тезис: Одноразовое значение CSP (nonce) 04

  • Автоматическое проставление правильного nonce внедрённым элементам разрешает и их. Граница доверенного построения документа остаётся обязательной для выбранного решения.

    Проверить тезис: Одноразовое значение CSP (nonce) 05

Финишная прямая

Проверьте инженерное мышление

Вопросы проверяют не память на аббревиатуры, а умение не делать лишних выводов.

01Во встроенном скрипте изменили пробелы и перевод строки, сохранив поведение. Как проверить его разрешение hash-source?
02Предлагается одинаково декодировать Base64 и Base64url для всех хешей и nonce перед сравнением CSP. Что неверно в этом решении?
03Эффективный список содержит unsafe-inline и корректный hash-source. У встроенного скрипта нет подходящего хеша или nonce. Даёт ли unsafe-inline общий допуск в этом списке?
04Разработчик добавил в политику хеш программы, и проверка совпала. Что из этого следует без отдельного анализа программы?
05В одной политике заданы script-src 'unsafe-inline' и script-src-attr 'none'. Может ли общий список разрешить обработчик события в атрибуте вопреки специальной директиве?
06В политике отсутствует script-src-elem, но присутствуют script-src и default-src. Как выбрать список для проверки обычного элемента script?
07Политика CSP 3 содержит nonce, strict-dynamic и адрес CDN. Допущенный загрузчик программно создаёт скрипт по адресу, изменяемому посетителем. Ограничивает ли этот адрес прежний список CDN?
08В примере strict-dynamic один скрипт создан через document.createElement, другой — через document.write. Собственного nonce или подходящих данных целостности у них нет. Почему результаты могут различаться?
09Кнопке с обработчиком события добавили правильный nonce ответа. Можно ли считать, что обработчик получил тот же допуск nonce-source, что встроенный script?
10Чувствительный вызов разрешён по хешу в допускающей его политике с unsafe-hashes. Доказывает ли совпадение, что вызов произошёл через ожидаемую кнопку по намерению человека?
11Внешний скрипт имеет два распознанных хеша integrity. Политика разрешает первый, но не второй; другие пути допуска исключены. Каков результат ветки hash-source?
12В integrity остались один распознанный разрешённый хеш и одна нераспознанная запись. Сопоставление метаданных CSP прошло успешно. Что ещё нельзя считать доказанным этим шагом?
13Ответ содержит только блокирующую CSP default-src 'none'. Можно ли по одной этой директиве заключить, что другой сайт не сможет встроить защищаемую страницу?
14frame-ancestors указана только в meta внутри HTML. HTTP-политики с этой директивой нет. Как трактует такую доставку модель CSP 3?
15Защищаемый документ встроен разрешённым порталом, но сам портал вложен во внешний документ, чей источник не разрешён frame-ancestors. Что даёт проверка предков в блокирующем режиме?
16Ответ имеет X-Frame-Options DENY и frame-ancestors только в Content-Security-Policy-Report-Only. Достаточно ли этого по модели CSP 3, чтобы игнорировать X-Frame-Options?
17Первая блокирующая политика запрещает соединение, вторая разрешает нужный адрес. Может ли разрешение второй отменить запрет первой?
18В тесте получен отчёт нарушения политики Content-Security-Policy-Report-Only. Какой вывод допустим по одному этому факту?
19В одном ответе три доверенных скрипта имеют одно правильно выданное значение nonce. Нужно ли менять его после исполнения первого скрипта?
20Шаблонизатор проставляет правильный nonce всем скриптам, включая пришедшие из пользовательского HTML. Проверка CSP совпадает. Какой вывод требует исправления решения?
Проверяемая база

Источники курса

Полные сведения о первоисточниках приведены один раз для всего курса. Под тезисами — ссылки на соответствующие утверждения Архивариума.

  • Первичная спецификация

    Content Security Policy Level 3

    World Wide Web Consortium · W3C Working Draft, 13 August 2026

    Прочитана сохранённая локальная HTML-копия. Алгоритмы разделов 6–7 отделены от ненормативных примеров раздела 8; редакция проекта не означает проверку поддержки каждого браузера.

    Открыть первоисточник
  • Официальная документация

    Cross Site Scripting Prevention Cheat Sheet

    OWASP Foundation · OWASP Cheat Sheet Series, checked 30 August 2026

    Определяет context-specific output encoding и safe sinks; CSP и WAF рассматривает как дополнительные, а не основные XSS controls.

    Открыть первоисточник
  • Первичная спецификация

    Content Security Policy Level 3

    World Wide Web Consortium · W3C Working Draft, 5 May 2026

    Определяет CSP directives, source lists, nonce-source и browser enforcement для загрузки и исполнения content.

    Открыть первоисточник

Delect.ru — информационный справочник: сведения о ценах, наличии и брендах формируются из данных витрины для анализа и сравнения. Наличие по данным витрины лучше дополнительно уточнять у выбранного поставщика; перед закупкой обязательно ставьте резервы. Сервис не является посредником при сделке и не сторона договора; коммерческие условия согласуются напрямую с выбранным дистрибьютором. Обозначения брендов приводятся для идентификации предложений.

Подтвердите действие