Пробная версия прекращения поддержки доступа к частной сети (PNA) для незащищенных контекстов завершается — внедрите запрос разрешения PNA

Ифань Ло
Yifan Luo
GitHub

Chrome 124 включает разрешение доступа к частной сети, позволяющее ослабить функцию смешанного контента . Для сайтов, которым требуется больше времени для подготовки к этому изменению, продолжается пробная версия прекращения поддержки , однако эта пробная версия заканчивается выпуском Chrome 126, который, как ожидается, выйдет 4 сентября 2024 года. В этом посте объясняется изменение, подробнее о дизайне этой функции и о том, как как перенести ваши текущие веб-сайты и как протестировать вашу реализацию.

Что меняется?

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

Что такое доступ к частной сети?

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

Зачем нужен запрос на разрешение?

В Chrome 94 введена блокировка доступа к частной сети с незащищенных общедоступных веб-сайтов. Продолжающееся испытание по прекращению поддержки доступа к частной сети из незащищенных контекстов выявило проблемы при переносе затронутых веб-сайтов на HTTPS. Общей проблемой является сложность перевода частных устройств на HTTPS, что приводит к нарушениям проверки смешанного контента.

Чтобы решить эту проблему, в исходную пробную версию Chrome 120 и в стабильную версию Chrome 124 был добавлен новый запрос разрешения.

Когда требуется запрос на получение разрешения?

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

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

Запустить запрос разрешения

Добавьте новый атрибут targetAddressSpace в качестве опции выборки, тогда запрос сможет пропустить проверку смешанного содержимого.

fetch("http://router.local/ping", {
  targetAddressSpace: "private",
});

В соответствии с «Доступом к частной сети: введение предполетной проверки» любому запросу частной сети предшествует предполетный запрос. Этот предварительный запрос будет включать новый заголовок Access-Control-Request-Private-Network: true , а соответствующий ответ должен включать заголовок Access-Control-Allow-Private-Network: true .

Чтобы разместить новый запрос разрешения, устройства должны включать два новых заголовка ответа: Private-Network-Access-Name и Private-Network-Access-ID .

  • Private-Network-Access-ID : 48-битное значение, представленное в виде 6 шестнадцатеричных байтов, разделенных двоеточиями.
  • Private-Network-Access-Name : допустимое имя в виде строки, соответствующей регулярному выражению ECMAScript /^[a-z0-9_-.]+$/. Максимальная длина имени — 248 кодовых единиц UTF-8.
Private-Network-Access-Name: "My Smart Toothbrush"
Private-Network-Access-ID: "01:23:45:67:89:0A"

Демо

Вы можете посмотреть демо-версию по адресу: https://private-network-access-permission-test.glitch.me/ .

Вам необходимо запустить свой личный частный сервер, чтобы использовать демонстрационный веб-сайт. Частный сервер должен ответить HTTP-заголовком Access-Control-Allow-Private-Network: true вместе с указанными сервером заголовками Private-Network-Access-ID и Private-Network-Access-Name . Если все настроено правильно, должен появиться следующий запрос разрешения:

Выйти из пробного периода прекращения поддержки незащищенного контекста

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

После обновления кода удалите пробный токен в заголовках HTML, JavaScript или HTTP. Если вы не помните, куда вы поместили пробный токен, обратитесь к разделу «Регистрация для прекращения поддержки пробной версии» в предыдущей записи блога.

Вы также можете удалить токен на странице пробной версии .

Что дальше?

Решение для запросов из fetch() , не использующих API, все еще находится в стадии разработки.

Было протестировано несколько решений, например, с использованием сервисных работников или созданием целевого адресного пространства в качестве новой политики Content-Security-Policy. Однако окончательная форма запросов от fetch() не связанной с API, все еще находится на стадии изучения.

В будущем запросы из подкадров могут поддерживаться политикой разрешений.

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

Отзывы о вариантах использования частной сети

Если вы размещаете веб-сайт в частной сети, которому требуются запросы из общедоступных сетей, команда Chrome хочет получить ваши отзывы! Сообщите о проблеме в Chromium Issue Tracker (компонент: Blink>SecurityFeature>CORS>PrivateNetworkAccess) или в репозитории GitHub .

Ресурсы