Зачем вам нужна «изолированная версия перекрестного происхождения»? для мощных функций

Узнайте, почему междоменная изоляция необходима для использования таких мощных функций, как SharedArrayBuffer , performance.measureUserAgentSpecificMemory() и таймер с высоким разрешением и большей точностью.

Введение

В статье «Как сделать ваш веб-сайт «изолированным от других источников» с помощью COOP и COEP» мы объяснили, как перейти в состояние «изолированности от других источников» с помощью COOP и COEP. Эта статья является дополнением и объясняет, почему изоляция от других источников необходима для включения мощных функций в браузере.

Фон

В основе веб-технологий лежит политика одного источника : функция безопасности, которая ограничивает взаимодействие документов и скриптов с ресурсами из других источников. Этот принцип ограничивает способы доступа веб-сайтов к ресурсам из разных источников. Например, документу с https://a.example запрещен доступ к данным, размещенным по адресу https://b.example .

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

  • Встраивание iframe из разных источников
  • Включите в список ресурсы из разных источников, такие как изображения или скрипты.
  • Открывать всплывающие окна из других источников с использованием ссылки на DOM.

Если бы веб-технологии можно было разработать с нуля, этих исключений не существовало бы. К сожалению, к тому времени, когда веб-сообщество осознало ключевые преимущества строгой политики одного источника, веб уже полагался на эти исключения.

Последствия для безопасности, вызванные такой мягкой политикой доступа к ресурсам из разных источников, были устранены двумя способами. Первый способ заключался во введении нового протокола, называемого Cross Origin Resource Sharing (CORS), цель которого — гарантировать, что сервер разрешает совместное использование ресурса с заданным источником. Второй способ — это неявное удаление прямого доступа скриптов к ресурсам из разных источников при сохранении обратной совместимости. Такие ресурсы из разных источников называются «непрозрачными» ресурсами. Например, именно поэтому манипулирование пикселями изображения из другого источника с помощью CanvasRenderingContext2D завершается неудачей, если к изображению не применен протокол CORS.

Все эти политические решения принимаются в рамках контекстной группы просмотра.

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

Долгое время сочетание CORS и непрозрачных ресурсов было достаточным для обеспечения безопасности браузеров. Иногда обнаруживались частные случаи (например, уязвимости JSON ), которые требовали исправления, но в целом принцип запрета прямого доступа на чтение к необработанным байтам ресурсов из разных источников оказался успешным.

Всё изменилось с появлением Spectre , которая делает потенциально читаемыми любые данные, загруженные в ту же группу контекста просмотра, что и ваш код. Измеряя время выполнения определённых операций, злоумышленники могут угадать содержимое кэшей ЦП, а следовательно, и содержимое памяти процесса. Такие атаки по времени возможны с использованием таймеров с низкой детализацией, существующих на платформе, но могут быть ускорены с помощью таймеров с высокой детализацией, как явных (например, performance.now() ), так и неявных (например, SharedArrayBuffer ). Если evil.com внедрит изображение из другого источника, они могут использовать атаку Spectre для чтения его пиксельных данных, что делает неэффективными средства защиты, основанные на «непрозрачности».

Изображение, на котором Spectr представлен в виде теневой фигуры на ноутбуке, взаимодействующей с группой контекстных окон просмотра, как обычный пользователь.

В идеале все междоменные запросы должны явно проверяться сервером, которому принадлежит ресурс. Если проверка не осуществляется сервером, владеющим ресурсом, то данные никогда не попадут в контекстную группу просмотра злоумышленника и, следовательно, останутся вне досягаемости любых атак Spectre, которые может осуществить веб-страница. Мы называем это состоянием междоменной изоляции. Именно в этом и заключается суть COOP+COEP.

В условиях междоменной изоляции запрашивающий сайт считается менее опасным, что открывает доступ к таким мощным функциям, как SharedArrayBuffer , performance.measureUserAgentSpecificMemory() и таймерам с высоким разрешением и большей точностью, которые в противном случае могли бы быть использованы для атак типа Spectre. Это также предотвращает изменение document.domain .

Политика встраивания из разных источников

Политика встраивания из других источников (COEP) предотвращает загрузку документом любых ресурсов из других источников, которые явно не предоставляют документу разрешение (с помощью CORP или CORS). С помощью этой функции вы можете указать, что документ не может загружать такие ресурсы.

Различные элементы страницы загружаются корректно, но воспроизведение видео останавливается из-за ошибки COEP, сопровождающейся сообщением об ошибке 'require-corp.'.

Для активации этой политики добавьте в документ следующий HTTP-заголовок:

Cross-Origin-Embedder-Policy: require-corp

Параметр COEP принимает единственное значение require-corp . Это обеспечивает соблюдение политики, согласно которой документ может загружать ресурсы только из того же источника или ресурсы, явно помеченные как загружаемые из другого источника.

Для того чтобы ресурсы могли быть загружены из другого источника, они должны поддерживать либо протокол совместного использования ресурсов между источниками (CORS), либо политику совместного использования ресурсов между источниками (CORP).

Совместное использование ресурсов между источниками

Если ресурс из другого источника поддерживает протокол совместного использования ресурсов между источниками (CORS) , вы можете использовать атрибут crossorigin для его загрузки на вашу веб-страницу, не опасаясь блокировки со стороны COEP.

<img src="https://third-party.example.com/image.jpg" crossorigin>

Например, если этот ресурс изображения предоставляется с заголовками CORS, используйте атрибут crossorigin , чтобы запрос на получение ресурса использовал режим CORS . Это также предотвратит загрузку изображения, если не установлены заголовки CORS.

Аналогичным образом, вы можете получать данные из разных источников с помощью метода fetch() , что не требует специальной обработки, если сервер отвечает правильными HTTP-заголовками .

Политика использования ресурсов из разных источников

Политика междоменных ресурсов (CORP) изначально была введена как опциональная функция для защиты ваших ресурсов от загрузки с другого источника. В контексте COEP, CORP может определять политику владельца ресурса в отношении того, кто может загружать ресурс.

Заголовок Cross-Origin-Resource-Policy может принимать три возможных значения:

Cross-Origin-Resource-Policy: same-site

Ресурсы, помеченные same-site могут быть загружены только с одного и того же сайта.

Cross-Origin-Resource-Policy: same-origin

Ресурсы, помеченные same-origin могут быть загружены только из одного и того же источника.

Cross-Origin-Resource-Policy: cross-origin

Ресурсы, помеченные как cross-origin могут быть загружены любым веб-сайтом. ( Это значение было добавлено в спецификацию CORP вместе с COEP.)

Политика открытия междоменных запросов

Политика открытия окон между источниками (COOP) позволяет гарантировать изоляцию окна верхнего уровня от других документов путем помещения их в другую группу контекста просмотра, чтобы они не могли напрямую взаимодействовать с окном верхнего уровня. Например, если документ с COOP открывает всплывающее окно, его свойство window.opener будет иметь значение null . Кроме того, свойство .closed ссылки на него со стороны открывающего окна вернет true .

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

Заголовок Cross-Origin-Opener-Policy может принимать три возможных значения:

Cross-Origin-Opener-Policy: same-origin

Документы, помеченные same-origin могут использовать ту же группу контекста просмотра, что и документы с тем же источником, которые также явно помечены same-origin .

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

Cross-Origin-Opener-Policy: same-origin-allow-popups

Документ верхнего уровня с same-origin-allow-popups сохраняет ссылки на любые свои всплывающие окна, которые либо не устанавливают COOP, либо отказываются от изоляции, устанавливая COOP равным unsafe-none .

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

Cross-Origin-Opener-Policy: unsafe-none

unsafe-none установлен по умолчанию и позволяет добавить документ в группу контекста просмотра открывающего его пользователя, если только у самого открывающего пользователя нет группы контекста просмотра same-origin .

Краткое содержание

Если вам нужен гарантированный доступ к мощным функциям, таким как SharedArrayBuffer , performance.measureUserAgentSpecificMemory() или таймеры с высокой точностью, помните, что ваш документ должен использовать COEP со значением require-corp и COOP со значением same-origin . В отсутствие любого из них браузер не гарантирует достаточной изоляции для безопасного включения этих мощных функций. Вы можете определить ситуацию на вашей странице, проверив, возвращает ли self.crossOriginIsolated true .

Узнайте, как это реализовать, в статье «Как сделать ваш веб-сайт "изолированным от других источников" с помощью COOP и COEP» .

Ресурсы