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

Ответ 1

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

• Это, возможно, проще, чем протоколы переключения.

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

• Следуя вашей ссылке, пользователь "Helios" делает отличную оценку, что использование 100% HTTPS гораздо менее запутанно для пользователя.

Ответ 2

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

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

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

Ответ 3

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

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

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

Ответ 4

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

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

Ответ 5

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

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

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

Update

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

Ответ 6

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

Ответ 7

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

Наличие формы в сеансе, отличном от HTTPS, нарушает эту уверенность.

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

Ответ 8

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

Ответ 9

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

Ответ 10

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

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

Ответ 11

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

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

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