Уменьшите риски, связанные с непреднамеренным доступом устройств и серверов во внутренней сети клиента к Интернету в целом.
Вредоносные веб-сайты, отправляющие запросы к устройствам и серверам, расположенным в частной сети, уже давно представляют угрозу. Злоумышленники могут, например, изменить конфигурацию беспроводного маршрутизатора, чтобы активировать атаки «Человек посередине» . CORS-RFC1918 — это предложение по умолчанию блокировать такие запросы в браузере и требовать от внутренних устройств согласия на запросы из общедоступного Интернета.
Чтобы понять, как это изменение повлияет на веб-экосистему, команда Chrome ищет отзывы разработчиков, создающих серверы для частных сетей.
Что не так со статус-кво?
Многие веб-серверы работают в частной сети — беспроводные маршрутизаторы, принтеры, веб-сайты интрасети, корпоративные службы и устройства Интернета вещей (IoT) — это лишь часть из них. Может показаться, что они находятся в более безопасной среде, чем те, которые открыты для публики, но эти серверы могут быть использованы злоумышленниками, использующими веб-страницу в качестве прокси. Например, вредоносные веб-сайты могут встраивать URL-адрес, который при простом просмотре жертвы (в браузере с поддержкой JavaScript) пытается изменить настройки DNS-сервера на домашнем широкополосном маршрутизаторе жертвы. Этот тип атаки называется « Drive-By Pharming » и произошел он в 2014 году . Более 300 000 уязвимых беспроводных маршрутизаторов были использованы для изменения настроек DNS, что позволило злоумышленникам перенаправлять пользователей на вредоносные серверы.
CORS-RFC1918
Чтобы снизить угрозу подобных атак, веб-сообщество представляет CORS-RFC1918 — совместное использование ресурсов между источниками (CORS), специализирующееся на частных сетях, определенных в RFC1918 .
Браузеры, реализующие CORS, проверяют целевые ресурсы, можно ли их загрузить из другого источника. Это достигается либо с помощью дополнительных встроенных заголовков, описывающих доступ, либо с помощью механизма, называемого предполетными запросами, в зависимости от сложности. Прочтите статью «Обмен ресурсами между источниками» , чтобы узнать больше.
С CORS-RFC1918 браузер по умолчанию блокирует загрузку ресурсов через частную сеть, за исключением тех, которые явно разрешены сервером с использованием CORS и HTTPS. Веб-сайт, отправляющий запросы к этим ресурсам, должен будет отправлять заголовки CORS, а серверу необходимо будет явно указать, что он принимает запрос из разных источников, отвечая соответствующими заголовками CORS. (Точные заголовки CORS все еще находятся в стадии разработки.)
Разработчикам таких устройств или серверов будет предложено сделать две вещи:
- Убедитесь, что веб-сайт, отправляющий запросы в частную сеть, обслуживается по протоколу HTTPS.
- Настройте поддержку сервера для CORS-RFC1918 и ответьте ожидаемыми заголовками HTTP.
Какие запросы затронуты?
Затронутые запросы включают в себя:
- Запросы из общедоступной сети в частную сеть
- Запросы из частной сети в локальную сеть
- Запросы из публичной сети в локальную сеть
Частная сеть Пункт назначения, который разрешается в частное адресное пространство, определенное в разделе 3 RFC1918 в IPv4, адрес IPv6, сопоставленный с IPv4, где сопоставленный адрес IPv4 сам по себе является частным, или адрес IPv6 за пределами ::1/128
, 2000::/3
Подсети 2000::/3
и ff00::/8
.
Локальная сеть. Пункт назначения, который разрешается в пространство «петлевой проверки» ( 127.0.0.0/8
), определенное в разделе 3.2.1.3 RFC1122 IPv4, пространство «локального канала» ( 169.254.0.0/16
), определенное в RFC3927 IPv4. , префикс «уникального локального адреса» ( fc00::/7
), определенный в разделе 3 RFC4193 для IPv6, или префикс «локального канала» ( fe80::/10
), определенный в разделе 2.5.6 RFC4291 для IPv6.
Публичная сеть Все остальные.
![Отношения между публичными, частными и локальными сетями в CORS-RFC1918.](https://developer.chrome.com/static/blog/cors-rfc1918-feedback/image/relationship-between-publ-b36a72c2b6ded.png?authuser=5&hl=ru)
Планы Chrome по включению CORS-RFC1918
Chrome внедряет CORS-RFC1918 в два этапа:
Шаг 1. Запросы к ресурсам частной сети будут разрешены только с веб-страниц HTTPS.
В Chrome 87 добавлен флаг, который требует, чтобы общедоступные веб-сайты отправляли запросы к ресурсам частной сети по протоколу HTTPS. Вы можете перейти по about://flags#block-insecure-private-network-requests
, чтобы включить его. Если этот флаг включен, любые запросы к ресурсу частной сети с HTTP-сайта будут заблокированы.
Начиная с Chrome 88, ошибки CORS-RFC1918 будут отображаться в консоли как ошибки политики CORS.
![Ошибки CORS-RFC1918 будут отображаться в консоли как ошибки политики CORS.](https://developer.chrome.com/static/blog/cors-rfc1918-feedback/image/cors-rfc1918-errors-be-r-b862b694a7ca2.png?authuser=5&hl=ru)
На панели «Сеть» Chrome DevTools вы можете установить флажок «Заблокированные запросы» , чтобы сосредоточиться на заблокированных запросах:
![Ошибки CORS-RFC1918 также будут отображаться как ошибки CORS на панели «Сеть».](https://developer.chrome.com/static/blog/cors-rfc1918-feedback/image/cors-rfc1918-errors-also-67275e6c8a037.png?authuser=5&hl=ru)
В Chrome 87 ошибки CORS-RFC1918 отображаются только в консоли DevTools как ERR_INSECURE_PRIVATE_NETWORK_REQUEST
.
Вы можете попробовать это самостоятельно, воспользовавшись этим тестовым сайтом .
Шаг 2. Отправка предполетных запросов со специальным заголовком
В будущем, когда общедоступный веб-сайт попытается получить ресурсы из частной или локальной сети, Chrome будет отправлять предварительный запрос перед фактическим запросом.
Запрос будет включать заголовок Access-Control-Request-Private-Network: true
в дополнение к другим заголовкам запроса CORS. Помимо прочего, эти заголовки идентифицируют источник запроса, обеспечивая детальный контроль доступа. Сервер может ответить заголовком Access-Control-Allow-Private-Network: true
, чтобы явно указать, что он предоставляет доступ к ресурсу.
Требуется обратная связь
Если вы размещаете веб-сайт в частной сети, которая ожидает запросов из общедоступных сетей, команда Chrome будет заинтересована в ваших отзывах и вариантах использования. Есть две вещи, которые вы можете сделать, чтобы помочь:
- Перейдите по
about://flags#block-insecure-private-network-requests
, включите флаг и посмотрите, отправляет ли ваш веб-сайт запросы к ресурсу частной сети, как ожидалось. - Если вы столкнулись с какими-либо проблемами или хотите оставить отзыв, сообщите о проблеме на crbug.com и установите для компонента значение
Blink>SecurityFeature>CORS>RFC1918
.
Пример обратной связи
Наш беспроводной маршрутизатор обслуживает веб-сайт администратора той же частной сети, но через HTTP. Если HTTPS требуется для веб-сайтов, в которых встроен веб-сайт администратора, это будет смешанный контент. Должны ли мы включить HTTPS на сайте администратора в закрытой сети?
Это именно тот тип обратной связи, который ищет Chrome. Пожалуйста, сообщите о проблеме, связанной с вашим конкретным вариантом использования, на crbug.com . Chrome будет рад услышать ваше мнение.