Необходимо войти в систему на странице https

Несколько экспертов по безопасности уже говорили, что страница входа должна быть на ssl https. Итак, что, если мой логин - это блок, который отображается на всех страницах. Означает ли это, что весь мой сайт должен быть https?

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

Изменить: тем, кто спросил, когда я отправлял вопрос, я попытался настроить щедрость, но система не позволила мне. Я проверил FAQ и увидел, что щедрость может быть отправлена через 2 дня после публикации вопроса. Вот почему вы еще не видите щедрости. Но я не буду выбирать ответ, пока не заработаю щедрость через 2 дня. Извините за любую путаницу.

Ответ 1

Я прочитал, что можно поместить форму на http, но опубликовать ее в https, но я прочитал, что кто-то говорит, что ее можно использовать с человеком в средней атаке. Может кто-то подтвердить это?

Да. Форма передается по HTTP, поэтому человек в середине может вносить в нее изменения (например, поэтому он отправляет учетные данные на свой собственный сервер до отправки формы).

практический ответ, как безопасно решить эту проблему.

Если безопасность действительно важна - используйте HTTPS для всего сайта. Даже после того, как пароль был отправлен, если вы вернетесь к HTTP, cookie можно украсть (см. Firesheep)

Если безопасность не так важна, не помещайте форму входа на каждую страницу. Просто укажите ссылку на страницу входа.

Ответ 2

Простой ответ "Да" ваша страница входа и остальные веб-сайты должны быть отправлены через SSL

И вот почему из FAQ по внедрению SSL:

Ответ 3

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

Как сказано выше, goreSplatter, вы можете легко установить цель формы в защищенную конечную точку (т.е. https://site.com/login), и защищенное соединение будет используется для отправки учетных данных пользователя и получения ответа.

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

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

Ответ 4

Если вы хотите, чтобы ваши данные были в безопасности, вы должны использовать SSL (сертифицированный) на своем сайте. Но вам не нужно иметь SSL, чтобы ваши пароли были безопасными. Например, вы можете использовать openID, facebook connect, twitter sign-in для обработки этой части для вас. Таким образом, никогда не передаются пароли через провод в текстовом формате.

Ответ 5

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

Logged In As <user_name> или Not Logged In
Login или Logout в зависимости от состояния

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

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

Ответ 6

Например, GMAIL имеет опцию в конфигурации, где вы можете включить SSL. Facebook, Twitter и все социальные сети не имеют SSL или не включены.

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

Хорошие ответы выше, плюс все и получить свою собственную идею по этому поводу!

Удачи.

Ответ 7

Я прочитал, что можно поместить форму на http, но опубликовать ее на https, но я прочитал, что кто-то сказал, что ее можно использовать с человеком в средней атаке.

Нет. Цель <form> - это новый вызов, выполняемый используемым браузером.

Если URL-адрес http://example.com/ был посещен, а содержимое страницы было отображено браузером, незащищенное соединение закрывается (да. Он может оставаться открытым [Keep-Alive], но запрос на этот URL-адрес завершен).

Для цели входа в сайт https://example.com/ SSL-сессия будет согласовываться между сервером и клиентом с использованием другого порта сервера (обычно 443) и никакие данные с предыдущей страницы (кроме, может быть, "Referer" ) не используются после.

Я прочитал, что можно поместить форму на http, но опубликовать ее в https, но я прочитал, что кто-то говорит, что ее можно использовать с человеком в средней атаке. Может кто-то подтвердить это?

Да. Форма передается по HTTP, поэтому человек в середине может вносить в нее изменения (например, поэтому он отправляет учетные данные на свой собственный сервер до отправки формы).

На компрометированном сайте не имеет значения, был ли контент защищен или нет. Содержимое сайта может быть доставлено через SSL, но код все еще может быть скомпрометирован.

Кроме того, файлы cookie могут быть украдены. Но это всего лишь текст. Это то, что ваш сайт делает с этим "текстом", - это то, что важно. Если вы полагаетесь на то, что "браузер" сообщает вашим сценариям, ваше приложение небезопасно. Используйте проверку файлов cookie (на основе IP, на основе браузера, независимо от того, на каком основании), поэтому файлы cookie не могут быть "украдены".

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

Ответ 8

Даже если вы попытались поместить блок входа в iframe, который использует https, атака "человек в середине" может легко изменить src этого iframe, так что вы либо сделаете loginbox ссылкой для входа (с https login страница), или вам понадобится больше ресурсов для запуска вашего сайта с помощью ssl для всех веб-страниц, у которых есть окно входа...