Безопасность первоначального перенаправления с http://example.com на https://example.com

Предположим, что http://example.com/<foo> систематически перенаправляет на https://example.com/<foo>. Я ввожу http://example.com в адресной строке браузера, и я вижу загрузку страницы, после чего адресная строка теперь отображает ровно https://example.com/ (без Unicode-хака, без пробельного хака и т.д.). Я подтверждаю, что это так (большинство пользователей этого не делают, но предположим, что в этом случае пользователь это сделал). Далее предположим, что мой браузер не уязвим к подмене адресной строки. Также предположим, что SSL-сертификат действителен.

В этой ситуации могу ли я доверять, что с этого момента моя сессия не уязвима к какой-либо атаке “человек посередине”? Могла ли MITM на начальном HTTP-соединении ввести что-то — кукурузу, скрытый фрейм, что угодно, что могло бы скомпрометировать последующую очевидную HTTPS-сессию?

_{Это подслучай: “Насколько безопасно перенаправлять пользователя с http://normal.bank.com на https://secure.bank.com?”, я хочу узнать подробности именно для этого случая.}

Помимо @WhiteWinterWolf’s и @Adi’s отличных ответов, есть еще одна вещь, о которой я подумал, это случай, когда приложение уязвимо к XSS при выводе значения куки.

Скажем, обычно значение куки выводится без кодирования, но поскольку куки обычно устанавливаются по HTTPS и не подвержены MITM, это не опасно, так как пользователь может атаковать только себя. Однако, если HTTP-запрос был перехвачен и кука была отравлена эксплойтом для этой XSS уязвимости, это может стать возможным вектором атаки в этом сценарии.

Разумеется, это не тот случай, когда запрос, не используя HTTPS, включая перенаправление, уязвим, поскольку эта кука могла бы быть установлена даже если “example.com” вовсе не слушал на порту 80: злоумышленник мог бы MITM любой другой HTTP-запрос, который жертва сделала, перенаправив их на “http://example.com“, который также перехватывает злоумышленник и отправляет ответ для перенаправления пользователя на их оригинальный сайт, но только после того, как кука “example.com” была отравлена.

Могу ли я доверять, что с этого момента моя сессия не уязвима к какой-либо атаке “человек посередине”?

Обновленные заметки: См. ответ Тимоти Болдуина относительно префиксов куки и записей DNS HTTPS. Однако это зависит от того, реализовал ли оператор сайта такие меры, подобно HSTS (обсуждаемом ниже).

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

Мой оригинальный ответ:

Единственный действительно безопасный способ просматривать в ненадежной сети — отключить все протоколы в браузере, кроме HTTPS (например, настроить локальный прокси, но установить в браузере использование недопустимого порта для всех протоколов, кроме HTTPS). HSTS может помочь, но если первый запрос будет перехвачен (например, с использованием техники, описанной здесь, даже прежде чем вы успели подумать о посещении “example.com“), вы все равно будете уязвимы.

Обновление ниже в связи с новым вопросом в комментариях:

[Я забыл ввести комментарий к вознаграждению] Я спрашиваю с точки зрения пользователя (хотя интересно знать, что сайт/приложение также должны делать). В каких обстоятельствах, набирая example.com в адресной строке браузера, я непосредственно попадаю на https://example.com/? В каких обстоятельствах, набирая http://example.com/, я непосредственно попадаю на https://example.com/? Если сначала производится запрос к http://example.com/, какие плохие вещи могут произойти, и как мне, как пользователю, узнать, что плохие вещи происходят? – Жиль

Если для “example.com” существует активная запись HSTS (либо заранее загруженная, либо если пользователь посещал ее ранее), и пользователь ввел либо "example.com", либо "http://example.com" в адресной строке, он сразу же перейдет на "https://example.com" без каких-либо HTTP-запросов.

Когда веб-приложение выдает политику HSTS агентам пользователя, соответствующие агенты пользователя ведут себя следующим образом:
Автоматически превращают любые небезопасные ссылки, ссылающиеся на веб-приложение, в безопасные ссылки. (Например, http://example.com/some/page/ будет изменено на https://example.com/some/page/ до обращения к серверу.)
Если безопасность соединения не может быть обеспечена (например, у TLS-сертификата сервера самоподписанный), показывается сообщение об ошибке и пользователю не разрешается доступ к веб-приложению.

Если не было записи HSTS и пользователь ввел "example.com" или "http://example.com" в адресной строке, сначала будет сделан небезопасный запрос к “http://example.com“, который обычно отвечает заголовком “Location: https://example.com/“. Это приведет к тому, что браузер загрузит HTTPS URL. Если пользователь хочет удостовериться, что ничего не было введено или изменено и что единственное, что произошло, это возвращение заголовка “Location“, ему следует очистить всю информацию о состоянии. Процесс этого должен быть следующим:

1. Закройте все другие окна и вкладки браузера – это гарантирует, что никакие другие HTTP-запросы не будут MITM’d и перенаправлены на “example.com“.
2. Отключите JavaScript в своем браузере. Это обеспечит отсутствие скрипта, который устанавливает куки с интервалом. Например, если была уязвимость XSS через значение куки, введенный скрипт мог бы поддерживать значение куки, сбрасывая его каждые несколько секунд. Т.н. зомби-кука.
3. Очистите куки, любое локальное хранение и данные любых плагинов браузера (например, локальный Flash/Silverlight). Это уберет большую часть информации о состоянии для сайта.
4. Нажмите “обновить” в браузере. Это гарантирует, что текущая загрузка страницы не была POST-запросом, так как пользователь получил бы сообщение об ошибке. POST мог ввести контент на страницу, если есть какие-либо уязвимости XSS.
5. Если нужно, снова включите JavaScript.

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

Если пользователь просматривает через ненадежную сеть, тогда он никогда не сможет быть на 100% защищен. Нет простых проверок на подмену, если все не находится в известном состоянии (поэтому либо начинать с чистого состояния/HTTPS, либо удалять всю информацию о состоянии). Да, они могут вручную проверять куки, но с хитрыми техниками злоумышленник мог бы очистить куку, как только скрипт будет вставлен на страницу.

Насколько я вижу, здесь существует две уязвимости:

• Не установлен флаг Secure. Исходный HTTP-запрос будет “утекать” куку сессии, либо из сессии, созданной экземпляром по адресу http://example.com, либо из предыдущей сессии, созданной экземпляром по адресу https://example.com. Один и тот же идентификатор сессии будет повторно использован -> Злоумышленник получит доступ к сессии.

• Исходный HTTP-запрос перехвачен, и ответ заменен на тот, который устанавливает куку с идентификатором сессии для сессии, начатой злоумышленником. Последующие запросы будут повторно использовать ту же куку. Это форма атак на фиксацию сессий.

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

Единственное решение, которое я вижу здесь, это аннулирование и пересоздание сессии, когда запрос отправляется на https://example.com, а затем использование криптографически надежных токенов в дополнение к куке сессии при последующих запросах. Токен должен использоваться один раз и только один раз.

Как упоминалось выше, все куки должны быть помечены как Secure (Owasp), но также, если вы ожидаете, что ваши пользователи будут получать доступ к вашему сайту только через SSL, вы должны включить строгую защиту передачи HTTP (HSTS – Wikipedia).

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

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

Если имя куки имеет префикс __Secure- или __Host-, браузер будет игнорировать любые попытки установить куку из обычного HTTP, с дополнительными ограничениями для префикса __Host-.

Это указывается в draft-ietf-httpbis-rfc6265bis и уже поддерживается во всех основных браузерах.

Кроме того, RFC 9460 определяет тип записи DNS HTTPS, присутствие которой заставляет веб-браузер не подключаться к чистому HTTP и может указывать другую информацию. Если клиент использует криптографическую аутентификацию DNS (например, DNSSEC или DNS через TLS), то клиент не будет подключаться, используя чистый HTTP, если отсутствие записи DNS HTTPS или отсутствие DNSSEC в зоне DNS не будет сертифицировано.

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

Я вижу следующие подводные камни:

1. Атака “человек посередине” явно возможна, если перехватчик может подделать ваш SSL-сертификат. Поэтому, если вы его поделились (с вашим CDN? с недобросовестным администратором вашего хостинга? с сотрудником, которому юридически запрещено признать, что его вызывали в суд за ключи?), это действительно возможный вектор атаки. Это также может произойти, если вы изначально сгенерировали слабые ключи (возможно, у вашей системы не хватало энтропии или использовался сломанный генератор случайных чисел?).

2. Ни один из корневых ЦП (CA), которому доверяет браузер, не может быть скомпрометирован. Обратите внимание, что их обычно очень и очень много, и для манипуляций “человек посередине” требуется лишь одна компрометация, чтобы подделать очевидно действительный SSL-сертификат для вашего домена. Также обратите внимание, что некоторые пользователи могут зависеть от своих поставщиков, которые могут (как Microsoft) по запросу накладывать новые корневые сертификаты ЦП, теоретически позволяя любую (законную?) атаку “человек посередине”, которую Microsoft (или любой из ЦП) может быть уговорен поддержать. Мы, конечно, можем надеяться, что только хорошие парни обладают такой властью над корпорациями.

3. Даже, казалось бы, не связанные уязвимости явно могут опровергнуть весь аргумент, даже те, которые могут называться функцией, а не ошибкой: представьте, что человек посередине изначально служит веб-страницу через HTTP, которая заставляет браузер переключиться на полноэкранный режим, а затем имитирует типичное окно браузера. Замечает ли ваш гипотетический супер-проверяющий пользователь, что адресная строка и ее содержимое — это лишь сложная эмуляция адресной строки его браузера…?

Поскольку исходный запрос был отправлен через HTTP, существует множество возможных векторов атаки, которые не зависят от куки или состояния сессии и не будут затронуты последующим перенаправлением на HTTPS, даже с заголовком HSTS от сервера.

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

1) Отправить 301/302 перенаправления на промежуточные URL для установки/загрузки вредоносного ПО вне браузера. Это может включать кейлоггеры и т.д. Очень ценно, так как злоумышленник может “отобрать” жертву, направляемую на интересующий сайт. Когда вредоносное ПО будет развернуто на цели, в конечном итоге браузер отправит ожидаемое перенаправление клиенту, и показ продолжается, как будто ничего не произошло.

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

3) Похожий на предыдущий, но использующий все доступные уязвимости для изменения конфигурации браузера. Это может быть использовано для включения утечки информации через скрытый канал, например, подсказки поиска или автодополнение ключевых слов. Или сочетать это с вариантом 1 и настроить браузер на проксирование SSL через код, выполняемый локально.

4) Загрузить целевую SSL-страницу в iframe и использовать уязвимости XSS для получения и эксплуатации учетных данных сессии, как только жертва войдет в систему.

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

Я уверен, что есть и другие широкие категории атак, которые я упускаю, но это начало для понимания того, что начальная сессия HTTP в HTTPS может открыть.