Что такое HTTP-заголовок «Upgrade-Insecure-Requests»?


221

Я сделал запрос POST на сайт HTTP (не HTTPS), проверил запрос в Chrome Developer Tools и обнаружил, что он добавил свой собственный заголовок перед отправкой на сервер:

Upgrade-Insecure-Requests: 1

После выполнения поиска Upgrade-Insecure-Requestsя могу только найти информацию о сервере, отправляющем этот заголовок:

Content-Security-Policy: upgrade-insecure-requests

Это кажется связанным, но все же сильно отличающимся, поскольку в моем случае КЛИЕНТ отправляет заголовок в Запросе , тогда как вся информация, которую я нашел, касается СЕРВЕРА, отправляющего связанный заголовок в Ответе .


Так почему же Chrome (44.0.2403.130 m) добавляет Upgrade-Insecure-Requestsк моему запросу и что он делает?


Обновление 2016-08-24:

Этот заголовок с тех пор был добавлен как Рекомендация кандидата W3C и теперь официально признан.

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

Upgrade-Insecure-Requests: 1Заголовок , используемый как HTTPS: 1 в предыдущей W3C Working Draft и был переименован спокойно на Chrome до изменения стало официально принято.

(Этот вопрос задавался во время этого перехода, когда не было официальной документации по этому заголовку, и Chrome был единственным браузером, который отправил этот заголовок.)


1
Firefox тоже это делает.
Дакаб

Должно быть новым; Сначала я занимаюсь разработкой для Firefox, и этот заголовок определенно не был отправлен из Firefox в прошлом году.
user193130

Ответы:


274

Краткий ответ: он тесно связан с Content-Security-Policy: upgrade-insecure-requestsзаголовком ответа, указывая на то, что браузер его поддерживает (и на самом деле предпочитает).

Это заняло у меня 30 минут поиска в Google, но я наконец нашел его в спецификации W3.

Путаница возникает из-за того, что заголовок в спецификации был HTTPS: 1, и именно так Chromium реализовал его, но после того, как это сломало множество плохо кодированных веб-сайтов (особенно WordPress и WooCommerce), команда Chromium извинилась:

«Я извиняюсь за поломку; я, очевидно, недооценил влияние, основанное на обратной связи во время разработки и бета-тестирования».
- Майк Уэст, в выпуске Chrome 501842

Их исправление состояло в том, чтобы переименовать его Upgrade-Insecure-Requests: 1, и спецификация с тех пор была обновлена, чтобы соответствовать.

Во всяком случае, вот объяснение из спецификации W3 (как оно появилось в то время) ...

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

...

Когда сервер встречает это предпочтение в заголовках HTTP-запроса, он ДОЛЖЕН перенаправить пользователя на потенциально безопасное представление запрашиваемого ресурса.

Когда сервер встречает это предпочтение в заголовках HTTPS-запроса, он ДОЛЖЕН включать Strict-Transport-Securityзаголовок в ответ, если хост запроса является HSTS-безопасным или условно HSTS-безопасным [RFC6797].


1
Я не понимаю этого. Я a.comи перенаправлю вас b.com, предоставив этот заголовок b.comи отправив некоторую информацию. Если вы не находитесь в безопасном канале b.com, уже может произойти нюхательная атака, потому что я отправил данные b.comвместе с моим запросом. Можете ли вы привести нас к простому сценарию, как сделать соединения более безопасными для пользователей?
Саид Нимати

@SaeedNeamati При очень строгой перспективе это не делает ничего более безопасным. Если у вас нормальные требования к безопасности, вы должны сначала подключиться через HTTPS и не полагаться на это. При этом я бы описал это в контексте идеи « Доверие при первом использовании », которая действительно помогает пассивно.
TNE

1
Я вижу это скорее как желание клиента, чем как инструмент безопасности. Это похоже на заголовок «DNT», сервер может его игнорировать, но все же он выражает желание клиента.
Дузун

Мой ответ может быть улучшен, чтобы правильно объяснить, как клиент и сервер согласовывают это. Не стесняйтесь предлагать улучшения, если хотите.
Саймон Ист

5

Это объясняет все это:

Директива HTTP-Content-Security-Policy (CSP) upgrade-insecure-запросы предписывает агентам пользователя обрабатывать все небезопасные URL-адреса сайта (те, которые обслуживаются по HTTP), как если бы они были заменены на безопасные URL-адреса (те, которые обслуживаются по HTTPS). Эта директива предназначена для веб-сайтов с большим количеством небезопасных устаревших URL-адресов, которые необходимо переписать.

Директива upgrade-insecure-reports оценивается перед block-all-mixed-content, и если она установлена, последняя фактически не работает. Рекомендуется устанавливать одну или другую директиву, но не обе.

Директива upgrade-insecure-reports не гарантирует, что пользователи, посещающие ваш сайт по ссылкам на сторонних сайтах, будут обновлены до HTTPS для навигации верхнего уровня и, таким образом, не заменят заголовок Strict-Transport-Security (HSTS), который должен по-прежнему быть установлен с соответствующим максимальным возрастом, чтобы гарантировать, что пользователи не будут подвергаться атакам разборки SSL.

Источник: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/upgrade-insecure-requests

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.