Безопасно ли отправлять из формы HTTP в HTTPS? - PullRequest
72 голосов
/ 08 ноября 2008

Допустимо ли отправлять из формы http через https? Кажется, что это должно быть безопасно, но это позволяет человеку в середине атаки ( здесь хорошая дискуссия ). Существуют сайты, такие как mint.com , которые позволяют вам входить со страницы http, но размещают сообщения https. На моем сайте просьба иметь целевую страницу http, но иметь возможность безопасного входа в систему. Разве это не стоит возможной угрозы безопасности, и я должен просто заставить всех пользователей перейти на защищенную страницу для входа (или сделать целевую страницу безопасной)?

Ответы [ 11 ]

52 голосов
/ 08 ноября 2008

Отправка формы со страницы http на страницу https зашифровывает данные в форме, когда они передаются в самых простых терминах. При атаке «человек посередине» браузер предупредит вас.

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

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

33 голосов
/ 08 ноября 2008

Есть ли причина , а не использовать HTTPS для всей транзакции? Если вы не можете найти очень хороший, используйте его!

  • Возможно, это проще, чем переключение протоколов.

  • Риск MITM реален.

  • Перейдя по вашей ссылке, пользователь «Гелиос» замечает, что использование 100% HTTPS намного меньше сбивает с толку пользователя.

16 голосов
/ 08 ноября 2008

Подобные вещи появляются во всей сети, особенно на сайтах, для которых регистрация необязательна. Тем не менее, это по своей сути небезопасно по весьма тонким причинам и дает пользователю ложное чувство безопасности. Я думаю, что недавно была статья об этом на codinghorror.com .

Опасность заключается в том, что, когда вы отправляете свою страницу с целью публикации "https://xxx",, страница, на которой находится эта ссылка, небезопасна, поэтому злоумышленник может изменить ее при передаче, чтобы она указывала на любой URL-адрес злоумышленник желает. Поэтому, если я захожу на ваш сайт, я должен просмотреть источник, чтобы убедиться, что мои учетные данные отправляются на защищенный адрес, и эта проверка имеет отношение только для этой конкретной отправки. Если я вернусь завтра, Я должен снова просмотреть источник, поскольку эта конкретная доставка страницы могла быть атакована, а цель публикации была сорвана - если я не проверяю каждый раз, к тому времени, когда я узнаю, что цель публикации была сорвана, уже слишком поздно - я ' Мы уже отправили мои учетные данные на URL злоумышленника.

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

10 голосов
/ 16 ноября 2008

IE Blog объясняет: Критическая ошибка № 1: страницы входа без HTTPS (даже при отправке на страницу HTTPS)

  • Как пользователь узнает, что форма отправляется через HTTPS? Большинство браузеров не имеют такой реплики пользовательского интерфейса.
  • Как пользователь мог узнать, что он переходит на нужную страницу HTTPS? Если форма входа была доставлена ​​через HTTP, нет гарантии, что она не была изменена между сервером и клиентом.
6 голосов
/ 08 ноября 2008

Джей и Киви правы насчет атаки MITM. Однако важно отметить, что злоумышленнику не нужно ломать форму и выдавать какое-либо сообщение об ошибке; злоумышленник может вместо этого вставить JavaScript, чтобы отправить данные формы дважды, один раз ему и один раз вам.

Но, честно говоря, вы должны спросить, какова вероятность того, что злоумышленник сможет перехватить вашу страницу входа и изменить ее в полете? Каково это по сравнению с риском (а) выполнить прямую атаку MITM в сеансе SSL и надеяться, что пользователь нажмет «ОК» для продолжения; (b) выполнение MITM при первоначальном перенаправлении на SSL (например, с http://example.com до https://example.com) и перенаправление на https://doma1n.com вместо этого, которое находится под контролем атакующего; (c) У вас есть дефект XSS, XSRF или SQL-инъекции где-то на вашем сайте.

Да, я бы предложил запустить форму входа в систему по протоколу SSL, нет никаких причин не делать этого. Но я бы не стал сильно волноваться, если бы это было не так, вероятно, есть гораздо более низко висящие фрукты.

Обновление

Ответ выше - с 2008 года. С тех пор появилось много дополнительных угроз. Например, доступ к сайтам из случайных ненадежных сетей, таких как точки доступа WiFi (где любой поблизости может быть в состоянии осуществить эту атаку). Теперь я бы сказал, что да, вам определенно следует зашифровать свою страницу входа и весь ваш сайт. Кроме того, теперь есть решения для первоначальной проблемы перенаправления (HTTP Strict Transport Security). Open Web Application Security Project предоставляет несколько руководств по передовым методам.

2 голосов
/ 08 ноября 2008

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

Наличие формы в сеансе, отличном от HTTPS, подрывает эту гарантию.

(я знаю - это просто еще один способ сказать, что форма подвергается атаке MITM).

2 голосов
/ 08 ноября 2008

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

1 голос
/ 11 июля 2011

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

Большая проблема здесь в том, что Google не любит искать защищенные страницы по уважительной причине, поэтому все те разработчики, которые задаются вопросом, почему бы не сделать все это безопасным, ну, если вы хотите, чтобы ваша страница была невидимой для Google, защитите ее все. Иначе, второй лучший вариант публикации с http на https - это меньшее из двух зол на данный момент?

1 голос
/ 30 июня 2010

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

1 голос
/ 08 ноября 2008

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...