Доступ к частной сети: предварительная проверка

Titouan Rigoudy

Eiji Kitamura

Yifan Luo

Обновления

• 7 июля 2022 г .: обновлен текущий статус и добавлено определение пространства IP-адресов.
• 27 апреля 2022 г .: Обновлено объявление о временной шкале.
• 7 марта 2022 г .: объявлен откат после обнаружения проблем в Chrome 98.

Введение

Chrome прекращает поддержку прямого доступа к конечным точкам частной сети с общедоступных веб-сайтов в рамках спецификации доступа к частной сети (PNA).

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

Цель состоит в том, чтобы защитить пользователей от атак с подделкой межсайтовых запросов (CSRF), нацеленных на маршрутизаторы и другие устройства в частных сетях. Эти атаки затронули сотни тысяч пользователей , что позволило злоумышленникам перенаправить их на вредоносные серверы.

План развертывания

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

1. В Chrome 104:

   • Chrome экспериментирует, отправляя предполетные запросы раньше запросов на подресурсы частной сети.
   • Сбои предварительной проверки отображают предупреждения только в DevTools, не влияя иным образом на запросы частной сети.
   • Chrome собирает данные о совместимости и обращается к наиболее пострадавшим веб-сайтам.
   • Мы ожидаем, что это будет широко совместимо с существующими веб-сайтами.

2. В Chrome 113 не раньше:

   • Это начнется только в том случае, если данные о совместимости покажут, что изменение достаточно безопасно, и при необходимости мы обратимся к нему напрямую.
   • Chrome требует, чтобы предварительные запросы были успешными, в противном случае запросы не выполняются.
   • В то же время начинается пробная версия прекращения поддержки , позволяющая веб-сайтам, затронутым этим этапом, запрашивать продление времени. Суд продлится не менее 6 месяцев.

Что такое доступ к частной сети (PNA)

Доступ к частной сети (ранее известный как CORS-RFC1918 ) ограничивает возможность веб-сайтов отправлять запросы на серверы в частных сетях.

В Chrome уже реализована часть спецификации: начиная с Chrome 96, только безопасные контексты могут отправлять запросы к частной сети. Подробности читайте в нашей предыдущей публикации в блоге .

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

Как PNA классифицирует IP-адреса и идентифицирует частную сеть

IP-адреса подразделяются на три пространства IP-адресов: public , private , local

Локальное пространство IP-адресов содержит IP-адреса, которые являются либо адресами обратной связи IPv4 ( 127.0.0.0/8 ), определенными в разделе 3.2.1.3 RFC1122 , либо адресами обратной связи IPv6 ( ::1/128 ), определенными в разделе 2.5.3 RFC4291 .

Пространство частных IP-адресов содержит IP-адреса, которые имеют значение только в пределах текущей сети, включая 10.0.0.0/8 , 172.16.0.0/12 и 192.168.0.0/16 , определенные в RFC1918 , локальные адреса 169.254.0.0/16 определенные в RFC3927. , уникальные локальные одноадресные адреса IPv6 fc00::/7 определенные в RFC4193 , локальные одноадресные IPv6-адреса fe80::/10 определенные в разделе 2.5.6 RFC4291 , и IPv6-адреса, сопоставленные с IPv4, где сопоставленный IPv4-адрес сам по себе является частным.

Пространство общедоступных IP-адресов содержит все остальные адреса, не упомянутые ранее.

Локальный IP-адрес считается более частным, чем частный IP-адрес, который считается более частным, чем общедоступный IP-адрес.

Дополнительные сведения см. в разделе Требуется обратная связь: CORS для частных сетей (RFC1918) .

Предполетные запросы

Фон

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

Запрос разрешения отправляется как HTTP-запрос OPTIONS со специальными заголовками запроса CORS, описывающими предстоящий HTTP-запрос. Ответ должен содержать определенные заголовки ответа CORS, явно подтверждающие предстоящий запрос.

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

Для предполетных запросов представлена ​​новая пара заголовков запроса и ответа:

• Access-Control-Request-Private-Network: true установлено для всех предполетных запросов PNA.
• Access-Control-Allow-Private-Network: true должно быть установлено для всех предполетных ответов PNA.

Предполетные запросы PNA отправляются для всех запросов частной сети, независимо от метода и режима запроса. Они отправляются перед запросами в режиме cors , а также в no-cors и во всех других режимах. Это связано с тем, что все запросы частной сети могут использоваться для атак CSRF, независимо от режима запроса и от того, доступно ли инициатору содержимое ответа.

Предварительные запросы для PNA также отправляются для запросов того же источника, если целевой IP-адрес является более частным, чем инициатор. Это отличается от обычного CORS, где предполетные запросы предназначены только для запросов между источниками. Предварительные запросы для запросов того же источника защищают от атак с перепривязкой DNS .

Примеры

Наблюдаемое поведение зависит от режима запроса .

Режим без CORS

Скажем https://foo.example/index.html встраивает <img src="https://bar.example/cat.gif" alt="dancing cat"/> , а bar.example разрешается в 192.168.1.1 , частный IP-адрес согласно RFC 1918 .

Chrome сначала отправляет предполетный запрос:

HTTP/1.1 OPTIONS /cat.gif
Origin: https://foo.example
Access-Control-Request-Private-Network: true

Чтобы этот запрос был успешным, сервер должен ответить:

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://foo.example
Access-Control-Allow-Private-Network: true

Затем Chrome отправит фактический запрос:

HTTP/1.1 GET /cat.gif
...

На что сервер может нормально ответить.

режим CORS

Скажем https://foo.example/index.html запускает следующий код:

await fetch('https://bar.example/delete-everything', {
  method: 'PUT',
  credentials: 'include',
})

Опять же, скажем, bar.example разрешается в 192.168.1.1 .

Chrome сначала отправляет предполетный запрос:

HTTP/1.1 OPTIONS /delete-everything
Origin: https://foo.example
Access-Control-Request-Method: PUT
Access-Control-Request-Credentials: true
Access-Control-Request-Private-Network: true

Чтобы этот запрос был успешным, сервер должен ответить:

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://foo.example
Access-Control-Allow-Methods: PUT
Access-Control-Allow-Credentials: true
Access-Control-Allow-Private-Network: true

Затем Chrome отправит фактический запрос:

HTTP/1.1 PUT /delete-everything
Origin: https://foo.example

На что сервер может ответить в соответствии с обычными правилами CORS:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://foo.example

Как узнать, затронут ли ваш сайт

Начиная с Chrome 104, при обнаружении запроса частной сети перед ним будет отправлен предполетный запрос. Если этот предварительный запрос завершится неудачно, окончательный запрос все равно будет отправлен, но на панели проблем DevTools появится предупреждение.

Затронутые предполетные запросы также можно просмотреть и диагностировать на сетевой панели:

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

Чтобы просмотреть, что произойдет, если была реализована успешная предварительная проверка, вы можете передать следующий аргумент командной строки , начиная с Chrome 98:

--enable-features=PrivateNetworkAccessRespectPreflightResults

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

Что делать, если ваш сайт пострадал

Когда это изменение появится в Chrome 104, ожидается, что оно не нарушит работу какого-либо веб-сайта. Однако мы настоятельно рекомендуем вам обновить затронутые пути запросов, чтобы ваш веб-сайт продолжал работать должным образом.

Вам доступны два решения:

1. Обработка предполетных запросов на стороне сервера
2. Отключить проверки PNA с помощью корпоративных политик

Обработка предполетных запросов на стороне сервера

Обновите целевой сервер всех затронутых выборок для обработки предполетных запросов PNA. Во-первых, реализуйте поддержку стандартных предполетных запросов CORS на затронутых маршрутах. Затем добавьте поддержку двух новых заголовков ответов .

Когда ваш сервер получает предполетный запрос (запрос OPTIONS с заголовками CORS), сервер должен проверить наличие заголовка Access-Control-Request-Private-Network: true . Если этот заголовок присутствует в запросе, сервер должен проверить заголовок Origin и путь запроса вместе с любой другой соответствующей информацией (например, Access-Control-Request-Headers ), чтобы убедиться, что запрос можно безопасно разрешить. Обычно вам следует разрешить доступ к одному источнику, находящемуся под вашим контролем.

Как только ваш сервер решит разрешить запрос, он должен ответить 204 No Content (или 200 OK ) с необходимыми заголовками CORS и новым заголовком PNA. Эти заголовки включают Access-Control-Allow-Origin и Access-Control-Allow-Private-Network: true , а также другие по мере необходимости.

Обратитесь к примерам конкретных сценариев.

Отключите проверки доступа к частной сети с помощью корпоративных политик.

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

• InsecurePrivateNetworkRequestsAllowed
• InsecurePrivateNetworkRequestsAllowedForUrls

Дополнительную информацию см. в разделе Общие сведения об управлении политиками Chrome .

Оставьте нам отзыв

Если вы размещаете веб-сайт в частной сети, которая ожидает запросов из общедоступных сетей, команда Chrome будет заинтересована в ваших отзывах и вариантах использования. Сообщите нам об этом, сообщив о проблеме с Chromium на crbug.com и задав для компонента значение Blink>SecurityFeature>CORS>PrivateNetworkAccess .

Что дальше

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

Затем Chrome расширит проверки доступа к частной сети, чтобы охватить навигацию, включая iframe и всплывающие окна. Мы ориентировочно стремимся к тому, чтобы Chrome 108 начал показывать предупреждения.

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

Благодарности

Фотография на обложке Марка Олсена на Unsplash .