Блокировка чтения из разных источников | Cross-Origin Read Blocking (CORB)

В этом документе описывается блокировка чтения из разных источников — Cross-Origin Read Blocking (CORB), алгоритм, с помощью которого веб-браузеры могут идентифицировать и блокировать загрузку сомнительных ресурсов из разных источников до того, как они достигнут веб-страницы. CORB снижает риск утечки конфиденциальных данных, удерживая их подальше от веб-страниц с разными источниками. В большинстве браузеров он хранит такие данные вне контекста выполнения ненадежных скриптов. В браузерах с изоляцией сайта он может полностью скрыть такие данные от ненадежных процессов рендеринга, помогая даже против атак по побочным каналам.

 

Оглавление

1. Эта проблема
2. Какие атаки смягчает CORB?
3. Как CORB блокирует ответ?
4. Какие типы запросов подходят для CORB?
5. Какие типы контента защищает CORB?

5.1 Защита JSON
5.2 Защита HTML
5.3 Защита XML

6. Определение того, защищен ли ответ CORB
7. CORB и веб-совместимость

7.1 Наблюдаемое влияние CORB на изображения
7.2 Наблюдаемое влияние CORB на мультимедиа
7.3 Наблюдаемое влияние CORB на скрипты
7.4 Наблюдаемое влияние CORB на таблицы стилей
7.5 Наблюдаемое влияние CORB на другие функции веб-платформы
7.6 Количественная оценка воздействия CORB на существующие веб-сайты

Приложение: Дальнейшая работа — защита большего количества типов ресурсов
Приложение: CORB и веб-стандарты
Приложение: статус реализации CORB

 

1. Эта проблема

Политика одного источника (same-origin policy) обычно не позволяет одному источнику читать произвольные сетевые ресурсы из другого источника. На практике реализация этой политики не так проста, как блокирование всех загрузок из разных источников: должны быть установлены исключения для веб-функций, таких как <img> или <script>, которые могут нацеливаться на ресурсы из разных источников по историческим причинам, а также для механизма CORS. что позволяет выборочно читать некоторые ресурсы из разных источников.

Однако некоторые типы контента могут оказаться несовместимыми со всеми исторически разрешенными разрешительными контекстами. JSON является одним из таких типов: ответ JSON приведет к ошибке декодирования при нацеливании тега <img>, либо к ошибке отсутствия операции, либо к синтаксической ошибке при нацеливании на тег <script> и т. д.. Единственный случай, когда веб-страница может загружать JSON с наблюдаемыми последствиями, — это использование fetch() или XMLHttpRequest; и в этих случаях чтение из разных источников модерируется CORS.

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

 

2. Какие атаки смягчает CORB?

CORB смягчает следующие векторы атак:

Cross-Site Script Inclusion (XSSI) — Включение межсайтовых скриптов

XSSI — это метод указания тега <script> на целевой ресурс, который не является JavaScript, и наблюдения за некоторыми побочными эффектами, когда полученный ресурс интерпретируется как JavaScript. Ранний пример этой атаки был обнаружен в 2006 году: путем перезаписи конструктора массива JavaScript содержимое списков JSON можно было перехватить так же просто, как: <script src = «https://example.com/secret.json»>. Хотя вектор атаки конструктора массива фиксирован в текущих браузерах, в последующее десятилетие было обнаружено и исправлено множество подобных эксплойтов. Например, смотри Слайды здесь.

CORB предотвращает этот класс атак, потому что ресурс, защищенный CORB, будет заблокирован от того, чтобы когда-либо был доставлен межсайтовому элементу <script>.

CORB особенно ценен при отсутствии других средств защиты XSSI, таких как токены XSRF и/или префиксы безопасности JSON. Кроме того, наличие средств защиты XSSI, таких как префиксы безопасности JSON, также может использоваться как сигнал алгоритму CORB о том, что ресурс должен быть защищен CORB.

Speculative Side Channel Attack (e.g. Spectre) — Спекулятивная атака по побочному каналу (например, Spectre)

Например, злоумышленник может использовать элемент <img src = «https://example.com/secret.json»> для извлечения межсайтового секрета в процесс, в котором выполняется JavaScript злоумышленника, а затем использовать спекулятивный побочный канал атаки (например, Spectre), чтобы прочитать секрет.

CORB может предотвратить этот класс атак при использовании в тандеме с изоляцией сайта Site Isolation, предотвращая присутствие ресурса JSON в памяти процесса, на котором размещена межсайтовая страница.

 

3. Как CORB блокирует ответ?

Когда CORB решает, что ответ должен быть защищен CORB, ответ изменяется следующим образом:

• Тело ответа заменяется пустым.
• Заголовки ответа удаляются.

[lukasza@chromium.org] Chromium в настоящее время сохраняет заголовки Access-Control- * (это помогает лучше генерировать сообщения об ошибках для CORS).

Чтобы эффективно противостоять спекулятивным атакам по побочным каналам, блокировка CORB должна иметь место до того, как ответ достигнет процесса, в котором находится инициатор запроса из разных источников. Другими словами, блокировка CORB должна препятствовать тому, чтобы данные ответа, защищенные CORB, когда-либо присутствовали в памяти процесса, на котором размещен веб-сайт с перекрестным происхождением (даже временно или на короткий срок). Это отличается от концепции отфильтрованных ответов (например, отфильтрованный ответ CORS или непрозрачный отфильтрованный ответ), которые просто обеспечивают ограниченное представление полных данных, которые остаются сохраненными во внутреннем ответе и могут быть реализованы внутри процесса рендеринга.

Демонстрационная страница CORB доступна здесь.

 

4. Какие типы запросов подходят для CORB?

Следующие типы запросов освобождены от CORB:

• навигационные запросы или запросы, в которых адресатом запроса является «объект» (object) или «встраивание» (embed). Перекрестные источники <iframe>, <object> и <embed> создают отдельный контекст безопасности и, таким образом, представляют меньший риск утечки данных. В большинстве браузеров этот отдельный контекст означает, что у вредоносной страницы будет больше проблем с выводом содержимого, чем с его загрузкой в собственный контекст выполнения и наблюдением за побочными эффектами (например, XSSI, тегами стилей и т. д.). В браузерах с изоляцией сайта этот контекст безопасности использует отдельный процесс, полностью удаляя данные из адресного пространства вредоносной страницы.

[lukasza@chromium.org] TODO: выяснить, как работает изоляция на основе виртуальных машин Edge (например, если некоторые источники недоступны в определенных средствах визуализации, это значительно повысит полезность CORB в Edge).

• Запросы на загрузку (например, запросы, инициатором которых является «загрузка» (download)). В этом случае данные из ответа сохраняются на диск (вместо того, чтобы делиться с контекстом из разных источников) и, следовательно, не получают преимуществ от защиты CORB.

[lukasza@chromium.org] AFAIK, в Chrome ответ на запрос загрузки никогда не проходит через память процесса рендеринга. Не уверен, что это правда в других браузерах.

Все другие типы запросов могут быть удовлетворены CORB. Это включает:

• XHR and fetch()
• ping, navigator.sendBeacon()
• <link rel="prefetch" ...>
• Запросы со следующим адресатом запроса:
  • Запросы «изображения» (image), такие как тег <img> , /favicon.ico, SVG‘s <image>, CSS’ background-image, и так далее.
  • Запросы «сценария» назначения, такие как <script>,  importScripts(), navigator.serviceWorker.register(), audioWorklet.addModule(), и так далее.
  • Запросы «аудио» (audio), «видео» (video) или «треков» (track)
  • Запросы «шрифтов» (font)
  • Запросы «стилей» (style)
  • Запросы «отчётов» (report) такие как отчеты CSP, отчеты NEL и т. д.

Основная идея CORB состоит в том, чтобы рассмотреть, может ли конкретный ресурс быть непригодным для использования в каждом контексте, перечисленном выше. Если каждое возможное использование приведет либо к ошибке CORS, ошибке синтаксиса/декодирования, либо к отсутствию наблюдаемых последствий, CORB должен иметь возможность блокировать загрузку из разных источников без изменения наблюдаемых последствий загрузки. До CORB детали уже подавлялись от ошибок перекрестного происхождения, чтобы предотвратить утечку информации. Таким образом, наблюдаемые последствия таких ошибок уже ограничены, и их можно сохранить при блокировке.

 

5. Какие типы контента защищает CORB?

Как обсуждается ниже, следующие типы контента защищены CORB:

• JSON
• HTML
• XML

Каждый из них обсуждается в следующих разделах.

5.1 Защита JSON

JSON — широко используемый формат данных в Интернете; поддержка JSON встроена в веб-платформу. Ответы JSON, скорее всего, будут содержать данные пользователя, которые стоит защитить. Кроме того, в отличие от форматов HTML или изображений, не существует устаревших механизмов HTML (то есть предшествующих CORS), которые позволяют встраивать ресурсы JSON из разных источников.

Поскольку синтаксис JSON является производным от JavaScript и перекрывается с ним, необходимо учитывать возможность появления полиглотов JavaScript/JSON. CORB обрабатывает следующие случаи для JSON:

• Непустой литерал объекта JSON: непустой объект JSON (например, {«key»: «value»}). Это как раз подмножество синтаксиса JSON, которое является недопустимым синтаксисом JavaScript — двоеточие после первого строкового литерала вызовет синтаксическую ошибку. CORB может защитить эти случаи, даже если они помечены другим Content-Type, путем сниффинга тела ответа.
• Другие литералы JSON: оставшееся подмножество синтаксиса JSON (например, null или [1, 2, «3»]) также является допустимым синтаксисом JavaScript. В частности, когда они оцениваются как сценарий, они представляют собой выражения значений, которые не должны иметь побочных эффектов. Таким образом, если они могут быть обнаружены, они могут быть защищены CORB. Обнаружение здесь возможно, но требует реализации валидатора, который понимает полный синтаксис JSON:
  • Если ответ не помечен типом содержимого JSON, CORB может обнаружить эти случаи путем буферизации и проверки всего тела ответа как JSON; весь ответ должен быть рассмотрен из-за возможности наличия действительной программы JavaScript, имеющей побочные эффекты, такой как [1, 2, «3»].map(…).
  • Если ответ действительно помечен типом содержимого JSON, CORB может решить прослушать ответ, чтобы подтвердить, что он является действительным JSON, но не более определенного количества байтов. Это позволит избежать буферизации и синтаксического анализа неограниченного объема памяти.
• JSON обслуживается с префиксом, препятствующим XSSI: в качестве смягчения прошлых уязвимостей браузера многие реальные веб-сайты и фреймворки используют соглашение о префиксе своих извлекаемых ресурсов строкой, предназначенной для принудительной ошибки JavaScript. Эти префиксы не были стандартизированы до CORB, но несколько подходов кажутся преобладающими:
  • Последовательность символов )]}’ встроена в структуру фреймворка angular.js, среду Java Spring и широко используется в домене google.com.
  • Последовательность символов {} && исторически была встроена в среду Java Spring.
  • Бесконечные циклы, такие как for(;;);, широко используются в домене facebook.com.

Наличие этих распознаваемых средств защиты XSSI является сильным сигналом для алгоритма CORB о том, что ресурс должен быть защищен CORB. Таким образом, эти префиксы должны активировать защиту CORB почти в каждом случае, независимо от того, что за ними следует. Это считается безопасным, потому что:

• • Префикс безопасности JSON может вызвать синтаксическую ошибку (или зависание), если он присутствует в документе, обслуживаемом с помощью типа MIME JavaScript, такого как text/javascript.
  • Префиксы безопасности JSON, как известно, не конфликтуют с двоичными ресурсами, такими как изображения, видео или шрифты (которые обычно требуют, чтобы первые несколько байтов были жестко закодированы в определенной последовательности — например, FF D8 FF для image/jpeg).
  • Конфликты с таблицами стилей text/css теоретически возможны, потому что можно создать файл, который начинается с префикса безопасности JSON, но при этом отлично разбирается, как таблица стилей. text/css поэтому устанавливается как исключение, хотя практическая вероятность такого сценария кажется низкой. См. Ниже пример такой таблицы стилей:

 

)]}'
{}
h1 { color: red; }

JSON также используется некоторыми веб-функциями. Одним из примеров является <link rel = «manifest»>, атрибут href которого указывает файл манифеста JSON. К счастью, для этого механизма требуется CORS, когда в манифесте указано перекрестное происхождение, поэтому его обработка CORB работает идентично правилам, применяемым к fetch().

[nick@chromium.org] TODO: Есть ли ссылка на спецификацию для того, чтобы JSON не имел побочных эффектов при интерпретации как скрипт?

 

5.2 Защита HTML

HTML может быть встроен в кросс-источник через <iframe> (как указано выше), но в противном случае HTML-документы могут быть загружены только с помощью fetch() и XHR, оба из которых требуют CORS. Обнюхивание HTML уже хорошо изучено, поэтому (в отличие от JSON) относительно легко идентифицировать ресурсы HTML с высокой степенью уверенности.

Был выявлен один неоднозначный случай полиглота, который CORB должен обрабатывать консервативно: комментарии в стиле HTML, которые являются частью синтаксиса JavaScript.

• CORB пропускает блоки комментариев HTML при сниффинге для подтверждения типа содержимого HTML. Это означает, что (в отличие от обычного анализа HTML) наличие строки «“<!—” не сразу подтверждает, что полученный ресурс является документом HTML — за комментарием HTML всё равно должен следовать действительный тег HTML.
• Кроме того, после окончания HTML-комментария сниффер CORB будет пропускать все символы до символа завершения строки. Это помогает приспособиться к правилу SingleLineHTMLCloseComment, которое может использовать символы SingleLineCommentChars после символов “—>”.

Примеры полиглотов html/javascript, которые наблюдались при использовании на реальных веб-сайтах:

<!--/*--><html><body><script type="text/javascript"><!--//*/
var x = "This is both valid html and valid javascript";
//--></script></body></html>

<!-- comment --> <script type='text/javascript'>
//<![CDATA[
var x = "This is both valid html and valid javascript";
//]]>--></script>

 

5.3 Защита XML

XML, как и JSON, является широко используемым форматом обмена данными, и, как и HTML, это формат документа, встроенный в веб-платформу (особенно через XmlHttpRequest).

Подтвердить тип содержимого XML с помощью сниффинга проще, чем JSON или HTML: XML обозначается шаблоном <?xml, которому, возможно, предшествует пробел.

Единственный идентифицированный случай XML, который требует особой обработки со стороны CORB, — это image/svg+xml, который является типом изображения. Все остальные mime-типы XML рассматриваются как защищенные CORB.

 

6. Определение того, защищен ли ответ CORB

CORB решает, нуждается ли ответ в защите (т. е. является ли ответ ресурсом JSON, HTML или XML) на основе следующего:

• Если ответ содержит заголовок ответа X-Content-Type-Options: nosniff, то ответ будет защищен CORB, если его заголовок Content-Type является одним из следующих:
  • HTML MIME type
  • XML MIME type (кроме image/svg+xml, который не подлежит CORB, как описано выше)
  • JSON MIME type
  • text/plain
• Если ответом является ответ 206, то ответ будет защищен CORB, если его заголовок Content-Type является одним из следующих:
  • HTML MIME type
  • XML MIME type (кроме image/svg+xml, который не подлежит CORB, как описано выше)
  • JSON MIME type
• В противном случае CORB пытается прослушать тело ответа:
  • HTML MIME type, который воспринимает как HTML, защищен CORB
  • XML MIME type (кроме image/svg+xml), который прослушивает XML, защищен CORB
  • JSON MIME type, который обнаруживает, что JSON защищен CORB
  • text/plain, который воспринимается как JSON, HTML или XML, защищен CORB
  • Любой ответ (кроме text/css), который начинается с префикса безопасности JSON, защищен CORB

Обнюхивание необходимо, чтобы избежать блокировки существующих веб-страниц, которые зависят от неверно помеченных ответов из разных источников (например, на изображениях, обслуживаемых как text/html). Без сниффинга CORB блокировал бы примерно в 16 раз больше ответов.

• CORB будет только обнюхивать, чтобы подтвердить классификацию на основе заголовка Content-Type (т.е. если заголовок Content-Type является text/json, тогда CORB будет обнюхивать JSON и не будет обнюхивать HTML или XML).
• Если некоторые элементы синтаксиса являются общими для типов MIME с защитой CORB и без защиты CORB, то эти элементы должны игнорироваться анализом CORB. Например, при поиске (защищенного CORB) HTML, CORB игнорирует и пропускает комментарии HTML, потому что они также могут присутствовать в (не защищенном CORB) JavaScript. Это отличается от правил обнюхивания HTML, используемых в других контекстах.
• Обнюхивание — это эвристика, требующая максимальных усилий, и для достижения наилучших результатов безопасности мы рекомендуем веб-разработчикам:
  • 1) помечать ответы правильным заголовком Content-Type
  • 2) отказаться от прослушивания с помощью заголовка X-Content-Type-Options: nosniff.

[nick@chromium.org] В этом разделе необходимо убедительное обоснование того, почему text/plain получает такую особую интерпретацию. В идеале данные, показывающие, что text/plain обычно используется для обслуживания HTML, JSON или XML. Обработка text/plain в нашей текущей реализации может быть артефактом более раннего прототипа, который запускался после стандартного анализа MIME, и, возможно, видел, что типы MIME text/plain применялись как тип MIME по умолчанию, когда в ответе отсутствовал Заголовок Content-Type.

Обратите внимание, что приведенное выше означает, что следующие ответы не защищены CORB:

• Ответы помечены как multipart/*. Это позволяет избежать анализа типов содержимого вложенных частей. Мы рекомендуем не поддерживать запросы с несколькими диапазонами для конфиденциальных документов.
• Ответы без заголовка Content-Type.
• Ответы с типом MIME JavaScript, например text/javascript. Сюда входит JSONP («JSON с заполнением»), который, в отличие от JSON, предназначен для чтения и выполнения в контексте перекрестного происхождения.

 

7. CORB и веб-совместимость

7.1 Наблюдаемое влияние CORB на изображения

CORB не должен оказывать заметного влияния на теги <img>, если только ресурс изображения 1) неправильно помечен с неправильным, не-изображением, защищенным CORB Content-Type и 2) обслуживается с ответом X-Content-Type-Options: nosniff. заголовок.

 

 

 

 

В дополнение к тегу HTML <img> приведенные выше примеры должны применяться к другим веб-функциям, использующим изображения, включая, но не ограничиваясь:

• /favicon.ico
• <image> от SVG,
• <link rel = «preload» as = «image» …> (смотри тест WPT: fetch/corb/preload-image-png-mislabeled-as-html-nosniff.tentative.sub.html)
• фоновое изображение background-image в таблицах стилей
• рисование изображений на (потенциально испорченном) HTML <canvas>

[lukasza@chromium.org] Предыдущие попытки заблокировать изображения nosniff с несовместимыми типами MIME не удались. Мы думаем, что CORB повезет больше, потому что он будет блокировать только подмножество типов MIME, защищенных CORB (например, он не будет блокировать application/octet-stream, как указано в ошибке Firefox)

 

7.2 Наблюдаемое влияние CORB на мультимедиа

Аудио- и видео- материалы должны оказывать такое же воздействие, как и изображения, хотя 206 ответов с большей вероятностью будут получены для медиа.

7.3 Наблюдаемое влияние CORB на скрипты

CORB не должен оказывать заметного влияния на теги <script>, за исключением случаев, когда защищенный CORB ресурс, не связанный с JavaScript, помеченный своим правильным типом MIME, загружается как сценарий — в этих случаях ресурс обычно приводит к синтаксической ошибке, но Пустое тело ответа, защищенного CORB, не приведет к ошибке.

 

 

 

 

В дополнение к HTML-тегу <script> приведенные выше примеры должны применяться к другим веб-функциям, использующим JavaScript, включая сценарии назначения, такие как importScripts(), navigator.serviceWorker.register(), audioWorklet.addModule() и т. д.

 

7.4 Наблюдаемое влияние CORB на таблицы стилей

CORB не должен оказывать заметного влияния на таблицы стилей.

 

 

 

 

 

7.5 Наблюдаемое влияние CORB на другие функции веб-платформы

CORB не влияет на следующие сценарии:

 

XHR и fetch()

CORB не имеет наблюдаемого эффекта, потому что XHR и fetch() уже применяют политику одного источника к ответам (например, CORB должен только блокировать ответы, которые могут привести к ошибкам XHR между источниками из-за отсутствия CORS).

 

Prefetch — Предварительная выборка

CORB блокирует доступ тела ответа к средству визуализации с перекрёстным происхождением, но CORB не препятствует кэшированию тела ответа процессом браузера (и последующей доставке в другой процесс модуля визуализации с таким же происхождением).

 

Tracking and reporting — Отслеживание и отчетность

Различные методы пытаются проверить, получил ли пользователь доступ к некоторому контенту, инициируя веб-запрос к HTTP-серверу, который регистрирует посещение пользователя. Веб-запрос часто запускается невидимым элементом img для HTTP URI, который обычно отвечает либо 204, либо коротким HTML-документом. Помимо тега img, веб-сайты могут использовать теги style, script и другие для отслеживания использования.

CORB не повлияет на эти методы, поскольку они не зависят от фактического содержимого, возвращаемого HTTP-сервером. Это также относится к другим веб-функциям, которым не важен ответ: маякам, пингам, отчетам о нарушениях CSP и т. д.

 

Service workers — Сервисные работники

Сервис-воркеры могут перехватывать запросы из разных источников и искусственно создавать ответ внутри сервис-воркера (т. е. без пересечения источников и/или границ безопасности). CORB не блокирует такие ответы.

Когда сервис-воркеры кэшируют фактические ответы из разных источников (например, в режиме запроса «no-cors»), ответы «непрозрачны», и поэтому CORB может блокировать такие ответы без изменения поведения сервис-воркера («непрозрачные» ответы имеют недоступное тело даже без CORB).

 

Blob and File API

Получение URL-адресов больших двоичных объектов из разных источников блокируется даже без CORB (смотри https://github.com/whatwg/fetch/issues/666).

Тест WPT: script-html-via-cross-origin-blob-url.sub.html (а также тесты для навигационных запросов, охватываемых фиксацией здесь).

 

Скрипты и плагины контента

Они не охватываются CORB — CORB предполагает, что соответствующие политики безопасности реализуются каким-либо другим механизмом для сценариев содержимого и подключаемых модулей (например, Adobe Flash реализует механизм, подобный CORS, через crossdomain.xml).

 

7.6 Количественная оценка воздействия CORB на существующие веб-сайты

CORB был включен в дополнительных режимах изоляции сайта и полевых испытаниях, а Chromium был оснащен инструментами для подсчета количества заблокированных ответов, отвечающих критериям CORB. (Ответы, отвечающие критериям CORB, исключают запросы навигации и загрузки; см. Раздел «Какие типы запросов соответствуют требованиям CORB?» Выше.) Наш анализ исходных данных из Chrome Canary в феврале 2018 года показывает низкую верхнюю границу количества обращений. наблюдаемый на веб-страницах, с возможностью дальнейшего понижения границ.

В целом, 0,961% всех ответов, отвечающих критериям CORB, заблокированы. Однако более половины из них уже являются пустыми ответами (т. е. фактически имеют заголовок ответа Content-Length: 0) и, таким образом, не вызывают никаких изменений в поведении (т. е. будут затронуты только заголовки, не включенные в безопасный список). Обратите внимание, что если бы обнюхивание было опущено, почти 20% ответов были бы заблокированы, поэтому обнюхивание является очевидной необходимостью.

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

 

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

0,115% всех ответов, отвечающих критериям CORB, могли быть заблокированы из-за заголовка nosniff или запроса диапазона. Это характерно для непустых ответов с кодом состояния, отличным от 204, запрошенных из контекста, который иначе не игнорирует неправильно маркированное содержимое nosniff (например, как теги сценария). В этой группе:

• 95,16% из них — это ответы nosniff, помеченные как HTML, запрошенные тегом изображения. Они заблокированы и могут содержать реальные изображения. Однако мы ожидаем, что многие из этих случаев действительно содержат HTML и в любом случае не будут отображаться в теге изображения (как мы наблюдали в одном случае).

[creis@chromium.org] Мы рассматриваем возможность дальнейшего снижения этого предела, проанализировав эти ответы, чтобы подтвердить, сколько из них может содержать реальные изображения.

Еще 3,76% из них — это запросы диапазона для text/plain текста из медиа-контекста. Мы еще не нашли примеров на практике, но мы рассматриваем возможность разрешить ответы на запросы диапазона для text/plain текста, чтобы избежать сбоев здесь.

0,014% всех ответов, отвечающих критериям CORB, были недопустимыми входными данными для тегов сценария, поскольку анализ CORB показал, что это были HTML, XML или JSON. Опять же, это характерно для непустых ответов, у которых нет кода состояния 204. Эти случаи должны иметь минимальный риск нарушения на практике (например, более половины имеют коды состояния ошибки и, вероятно, представляют собой неработающие ссылки), но технически возможно наблюдать разницу в зависимости от того, сообщается ли синтаксическая ошибка.

 

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

 

Приложение: Дальнейшая работа — защита большего количества типов ресурсов

Предлагаемая в настоящее время версия CORB защищает только ресурсы JSON, HTML и XML — другие конфиденциальные ресурсы необходимо защищать каким-либо другим способом. Один из возможных подходов — защитить такие ресурсы с помощью нераспознаваемых токенов XSRF, которые распространяются через JSON (который защищен CORB).

В будущем CORB может быть расширен для защиты дополнительных ресурсов следующим образом:

 

Покрытие большего количества типов MIME — Covering more MIME types

Вместо блокирования HTML, XML и JSON, защита CORB может быть расширена на все типы MIME, за исключением типов MIME, которые разрешены как используемые в <img>, <audio>, <video>, <script> и других подобных элементах, которые могут быть встроенным кросс-источником:

• JavaScript MIME type, например text/javascript, application/javascript или text/jscript
• text/css
• типы изображений, такие как типы, соответствующие image/*
• типы аудио или видео, такие как audio/*, video/* или application/ogg
• font/* или один из устаревших типов шрифтов
• Другие типы MIME, такие как application/octet-stream, text/vtt

Это расширение предлагает CORB-защиту для таких ресурсов, как файлы PDF или ZIP. CORB не будет выполнять сниффинг подтверждения для типов MIME, кроме HTML, XML и JSON (поскольку нецелесообразно обучать снифферу CORB все возможные типы MIME). С другой стороны, ценность прослушивания подтверждения для этих других типов MIME кажется низкой, поскольку неправильная маркировка контента как таких типов кажется менее вероятной, чем, например, неправильная маркировка как text/html.

[lukasza@chromium.org] Смотри также https://github.com/whatwg/fetch/issues/721

 

Заголовок согласия CORB — CORB opt-in header

Для защиты ресурсов, которые обычно могут быть встроены из разных источников, сервер может явно выбрать CORB с заголовком ответа HTTP. Это сделало бы возможным CORB-защиту таких ресурсов, как изображения или JavaScript (включая JSONP).

[lukasza@chromium.org] В настоящее время рассматриваются следующие сигналы согласия CORB:

• From-Origin: или Cross-Origin-Resource-Policy: заголовки — смотри https://github.com/whatwg/fetch/issues/687
• Заголовок Isolate-Me — смотри https://github.com/WICG/isolation

 

Приложение: CORB и веб-стандарты

Раздел CORB в спецификации Fetch охватывает обработку nosniff и 206 ответов с мая 2018 года.

Сниффинг подтверждения CORB еще не стандартизирован.

Некоторые аспекты CORB обсуждаются и могут со временем развиваться.

 

Приложение: статус реализации CORB

Отслеживание ошибок:

• Chrome: https://crbug.com/268640 and https://crbug.com/802835 and https://www.chromestatus.com/feature/5629709824032768
• Edge: https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/17382911/
• Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1459357
• Safari/WebKit: https://bugs.webkit.org/show_bug.cgi?id=185331

Статус тестов веб-платформы:

• Экспериментальные сборки
• Стабильные релизы

 

Информационные ссылки

Источник — https://chromium.googlesource.com/chromium/src/+/refs/heads/main/services/network/cross_origin_read_blocking_explainer.md