Защищенные HTTP-заголовки до перенаправления на HTTPS?

Question

Я пытаюсь управлять сайтом HTTPS, учитывая вероятность того, что некоторые запросы сначала попытаются получить незащищенное соединение по простому HTTP. Я могу успешно перенаправить http:// на https://, но этот подход, по-видимому, подвергает случайного пользователя неприемлемой уязвимости: поскольку URI и адрес хоста должны быть переданы до сервера, зная, будет ли/куда (повторно) направлять запрос, подслушиватель может просмотреть начальные заголовки HTTP-запроса/ответа. Пользователь может быть обломан eavesdropper, который, например, читает заголовок запроса http:// и обслуживает страницу, которая выглядит достаточно похожей на страницу, которую пользователь ожидает увидеть.

Может ли сервер выполнять промежуточное действие, например, перемещать HTTP-соединение до HTTPS до отправки клиентом заголовка запроса, чтобы передача заголовков запроса/ответа была такой же защищенной, как передача самого содержимого? Невозможно ли защитить передачу заголовков между клиентом и сервером, если соединение изначально не защищено?

Answer 1

Вы должны посмотреть HTTP Strict Transport Security (HSTS). Это позволит вашему сайту указывать modern browsers, что его следует загружать только через HTTPS.

Это все равно оставит ваших пользователей уязвимыми для атак типа «человек в середине» в первый раз, когда они посещают ваш сайт (TOFU). Вы можете только уменьшить это, получив свой сайт на preloaded HSTS list.

Answer 2

Да, это риск, и это уязвимость, с которой был создан протокол HTTP Struct Transport Protocol.

Идея заключается в том, что когда вы подключаетесь к сайту HTTPS, сервер отправляет обратно HTTP-заголовок вроде следующего:

Strict-Transport-Security "max-age=2592000;" 

Это говорит браузеру: «в течение следующих 30 дней (60 * 60 * 24 * 365 = 2592000) НЕ подключаться через HTTP, но вместо этого обновлять любой HTTP-запрос до HTTPS автоматически до вы отправляете запрос ». В Chrome вы видите 307 интернет-перенаправление в средствах разработчика.

Почему 30 дней? Ну, он должен быть кэшируемым для браузеров, чтобы быть полезным, и вы можете решить, как долго. Некоторые люди рекомендуют 1 или даже 2 года (31536000 или 63072000 секунд соответственно).

Вы также можете указать заголовок IncludeSubdomains так поддомены автоматически защищаются слишком (хотя они, очевидно, должны возвращать заголовок тоже в случае, если кто-то посещает подобласть непосредственно):

Strict-Transport-Security "max-age=2592000; includeSubDomains" 

Это необходимо для лучшей защиты для печенья поскольку поддельный поддомен может получить или установить файлы cookie для родительского домена и захватить сеанс. Однако это опасно, если субдомен не находится на HTTPS, что может не всегда проявляться. Например. Если вы используете свое основное доменное имя внутри и имеете сайт по адресу http://intranet.example.com, тогда он может перестать работать до тех пор, пока вы не обновите его до HTTPS или не измените политику и не дождитесь истечения предыдущего максимального времени.

Это по-прежнему оставляет за собой риск, поскольку первое подключение необходимо сделать, чтобы этот заголовок добавил эту политику в кеш браузера. Это доверие к политике первого использования (TOFU). Точно так же, если вы посещаете долгое время после получения политики, вы находитесь в той же ситуации. По этой причине вы можете отправить свой сайт в список предварительной загрузки, чтобы браузер вставлял ваш сайт в него, поэтому он всегда предполагает установку HSTS. Используйте этот сайт для этого: https://hstspreload.appspot.com. Это звучит здорово, но не без риска.После того, как вы отправите свой сайт в этот список, его практически невозможно удалить, поэтому в основном это постоянная приверженность HTTPS. Может быть, не плохо, но вы также должны иметь длительное истечение, установку IncludeSubdomains, а также добавить настройку преднагрузки:

Strict-Transport-Security "max-age=2592000; includeSubDomains; preload" 

Лично я считаю, что это перебор и потенциально очень опасно из-за того, что это вне вашего контроля и нелегко отменить. IMHO только высокопрофессиональные сайты (онлайн-банкинг, сайты электронной коммерции, Google, Facebook, Twitter ... и т. Д.) Должны беспокоиться о предварительной загрузке, но это ваш собственный выбор.

Более подробную информацию о моих сообщений в блоге: https://www.tunetheweb.com/security/http-security-headers/hsts/ https://www.tunetheweb.com/blog/dangerous-web-security-features/