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

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

Десять модулей и двадцать ситуаций разбирают разрешение кода по хешу, применимые директивы, strict-dynamic, старые обработчики, целостность внешних скриптов и frame-ancestors. Новые правила привязаны к проекту CSP Level 3 от 13 августа 2026 года; задачи не заменяют проверку поддержки целевых браузеров.

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

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

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

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

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

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

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

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

Модуль 2 из 10

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

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

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

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

Модуль 3 из 10

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

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

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

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

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

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

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

Модуль 4 из 10

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

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

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

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

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

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

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

Модуль 5 из 10

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

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

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

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

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

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

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

Модуль 6 из 10

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

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

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

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

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

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

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

Модуль 7 из 10

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

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

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

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

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

Модуль 8 из 10

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

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

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

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

Модуль 9 из 10

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

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

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

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

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

Модуль 10 из 10

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

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

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

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

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

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

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

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

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

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

01У встроенного скрипта изменили пробелы и добавили перевод строки, сохранив поведение программы. Можно ли оставить прежний разрешённый хеш без пересчёта?
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.

    Открыть первоисточник
Сообщить об ошибке

Опишите проблему — постараемся исправить как можно скорее.

Спасибо!

Получили ваше сообщение.
Подтвердите действие