Перенаправление http на https - плохая идея?

Question

Я читаю на эту страницу и там говорится, что если сайт использует SSL и пользователь пытается получить к нему доступ через обычное http, приложение не должно перенаправлять пользователя на https. Это должно просто заблокировать его. Может ли кто-нибудь проверить достоверность этого? Это звучит не очень хорошая идея, и мне интересно, каков реальный риск от простого перенаправления пользователя на https. Кажется, что за этим нет технических причин, просто это хороший способ обучить пользователя.

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

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

Один из лучших способов защитить свой приложение против MITM-атак и фишинговые атаки обучают ваши пользователи.

Answer 1

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

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

HSTS реализуется путем указания заголовка ответа, например Strict-Transport-Security: max-age=31536000. Соответствующие пользовательские агенты автоматически превратят небезопасные ссылки в безопасные ссылки, тем самым уменьшая риск атак «человек посередине». Кроме того, если существует риск, что сертификат не является безопасным, например, корневые полномочия не распознаются, затем отображается сообщение об ошибке и ответ не отображается.

Answer 2

Переход от HTTP к HTTPS на самом деле не очень хорошая идея. Например, злоумышленник может провести атаку «человек посередине», используя такой инструмент, как ssl strip . Для решения этой проблемы вы должны использовать протокол HSTS . Он поддерживается всеми основными браузерами (Internet Explorer, который является последним разработчиком, поддерживает его, начиная с IE12), и используется многими популярными сайтами (например, Paypal, Google).

Answer 3

Я не вижу никакого технического риска (кроме того, который указан в обновлении в конце моего ответа) при перенаправлении с HTTP на HTTPS. Например, Gmail и Yahoo Mail делают это. Вы можете проверить это с помощью средства отладки HTTP (например, Fiddler), где вы можете четко определить ответ перенаправления 302, возвращаемый сервером.

Я считаю, что блокировка - это плохая идея с точки зрения юзабилити. Часто пользователи вводят адрес в браузере без указания HTTP или HTTPS. Например, я получаю доступ к Gmail, набирая «mail.google.com», который по умолчанию равен «http://mail.google.com"» и автоматически перенаправляется на «https://mail.google.com".. Без автоматического перенаправления мне всегда придется вводить полный адрес.

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

Обновление @Pedro и @Spolto правы. Особое внимание следует уделить чувствительным файлам cookie (таким как файлы cookie сеанса или аутентификации), которые действительно должны быть помечены как безопасные, чтобы они передавались только по протоколу HTTPS. Я скучал по этому. +1 вы оба, ребята.

Answer 4

Я только что заметил этот вопрос, но я написал пару ответов на похожие вопросы:

• Webmasters.SE: Как запретить доступ к сайту без SSL-соединения?
• Принудительно использовать HTTPS для определенного URL

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

Кроме того, пользователь несет ответственность за проверку, чем он использует HTTPS (и что сертификат проверяется без предупреждения)когда они этого ожидают.

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

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

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

Answer 5

С технической точки зрения, IMO не имеет побочных эффектов, кроме того, что принимает HTTPS.

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

Answer 6

Это вполне приемлемый метод «начальной загрузки» - перенаправление 301 с HTTP на HTTPS, а затем на стороне HTTPS возвращает заголовок Strict-Transport-Security для блокировки браузера в HTTPS.

Было бы серьезной проблемой в удобстве использования для полной блокировки HTTP, так как веб-браузеры будут пытаться использовать протокол HTTP, когда URL вводится без обозначения протокола, если браузер не поддерживает HSTS и токен HSTS не найден ни в кэше браузера, ни в список предварительной загрузки.