Безопасно ли отправлять из HTTP-формы в HTTPS?

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

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

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

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

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

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

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

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

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

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

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

обновление

вышеуказанный ответ от 2008. С тех пор появилось много дополнительных угроз. Например, доступ к сайтам из случайных ненадежных сетей, таких как WiFi hotspots (где кто-нибудь рядом может быть в состоянии снять эту атаку). Теперь я бы сказал Да, вы определенно должны зашифровать свою страницу входа, а затем весь ваш сайт. Кроме того, теперь есть решения для начальной проблемы перенаправления (http Strict безопасность на транспорте.) Элемент Открыть Проект Безопасности Веб-Приложений предоставляет несколько руководств по передовой практике.

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

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

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

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

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

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

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

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

Я думаю, что основное рассмотрение этого вопроса связано с URL-адресом, который знают пользователи, и схемой протокола (http:), которую браузеры заменяют по умолчанию.

в этом случае нормальное поведение сайта, который хочет обеспечить шифрованный канал-это http://home-page перейти к https://home-page. Существует еще возможность спуфинга / MitM, но если это отравление DNS, риск не выше, чем если начать с https: URL. Если возвращается другое доменное имя,вам нужно беспокоиться.

Это, вероятно, достаточно безопасно. В конце концов, если вы подвержены целевому MitM, вы можете также начать беспокоиться о клавиатурных регистраторах, вашем локальном файле HOSTS и всевозможных других способах узнать о ваших безопасных транзакциях, связанных с вашей системой, которая уже принадлежит.