it-swarm.com.ru

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

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

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

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

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

56
sami

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

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

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

41
cspolton

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

22
Luca Invernizzi

Я не вижу никакого технического риска (за исключением того, который указан в обновлении в конце моего ответа) при перенаправлении с 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.

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

5
Florin Dumitrescu

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

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

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

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

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

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

4
Bruno

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

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

3
timdream

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

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

0
William