Несколько экспертов по безопасности заявили в прошлом, что страница входа должна быть на ssl https. Итак, что, если мой логин – это блок, который отображается на всех страницах. Означает ли это, что весь мой сайт должен быть https?
Я читал, что можно поместить форму на http, но опубликовать ее на https, но я прочитал, что кто-то говорит, что ее можно использовать с человеком в средней атаке. Может кто-то подтвердить это? У меня есть 100 баллов за кого-то, кто может это подтвердить (и помогите мне с практическим ответом, как это безопасно решить). Моя форма входа на каждую страницу, мне нужно сделать весь сайт на https? Пожалуйста, не стесняйтесь спрашивать все, что я сказал здесь. Это только то, что я читаю, но у меня нет опыта, и я сам не пробовал.
Редактировать: тем, кто спросил, когда я отправлял вопрос, я попытался настроить щедрость, но система не позволила мне. Я проверил FAQ и увидел, что щедрость может быть отправлена через 2 дня после публикации вопроса. Вот почему вы еще не видите щедрости. Но я не буду выбирать ответ, пока не заработаю щедрость через 2 дня. Извините за любую путаницу.
Я читал, что можно поместить форму на http, но опубликовать ее на https, но я прочитал, что кто-то говорит, что ее можно использовать с человеком в средней атаке. Может кто-то подтвердить это?
Да. Форма передается по HTTP, поэтому человек в середине может вносить в нее изменения (например, поэтому он отправляет учетные данные на свой собственный сервер до отправки формы).
практический ответ, как безопасно решить эту проблему.
Если безопасность действительно имеет значение – используйте HTTPS для всего сайта. Даже после того, как пароль был отправлен, если вы вернетесь к HTTP, cookie можно будет украсть (см. Firesheep )
Если безопасность не так важна, тогда не помещайте форму входа на каждую страницу. Просто укажите ссылку на страницу входа.
Простой ответ «Да» ваша страница входа и остальные веб-сайты должны быть переданы через SSL
И вот почему из FAQ по внедрению SSL:
Ну, если вы не используете SSL для входа в систему, пароль пользователя может быть раскрыт любому, у кого есть средства для прослушивания связи клиент-сервер (в основном чтение потока данных). (Что не хорошо ^^)
Как сказано выше, goreSplatter, вы можете легко установить целевой объект формы для защищенной конечной точки (т. Е. https://site.com/login ), и защищенное соединение будет использоваться для отправки учетных данных пользователя и получения ответа.
Большинство веб-сайтов затем продолжают связываться по базовому HTTP-протоколу, который «только» предоставляет своим пользователям риски захвата сеанса («человек в середине» считывает свой идентификатор сеанса / подпись / nonce / whatever, а затем делает вид, что он является аутентифицированным клиентом, поэтому, если он преуспеет, он может манипулировать защищенными ресурсами клиента, но этот метод не позволяет «красть всю учетную запись»). Обычно это считается незначительной угрозой и из-за накладных расходов, связанных с SSL-связью, защищенное соединение для всех запросов используется только в критических приложениях (например, онлайн-банкинг).
Наконец, чтобы ответить на ваш вопрос: Нет, обязательно должны быть обеспечены только передачи, в которых отправляются конфиденциальные данные.
Если вы хотите, чтобы ваши данные были в безопасности, вы должны использовать SSL (сертифицированный) на своем сайте. Но вам не нужно иметь SSL, чтобы ваши пароли были безопасными. Например, вы можете использовать openID, facebook connect, twitter sign-in для обработки этой части для вас. Таким образом, никогда не передаются пароли через провод в текстовом виде.
Есть ли у вас возможность перепроектировать концепцию пользовательского интерфейса? Идея: иметь пользовательский интерфейс входа в систему на каждой странице, но не фактический элемент управления. Ваш новый информационный контроль будет перечислять:
Logged In As <user_name> или Not Logged In Login или Logout зависимости от состояния Затем ссылки отображают всплывающее окно входа в систему, содержимое которого полностью защищено.
Такой подход приблизит вас к тому, что у вас уже есть (некоторые функции входа на каждую страницу), но маршрутизируется / накладывается таким образом, что ваша аутентификация полностью защищена через SSL.
Например, GMAIL имеет опцию в конфигурации, где вы можете включить SSL. Facebook, Twitter и все социальные сети не имеют SSL или не включены.
Я думаю, что если вы действительно хотите, чтобы безопасность вашего сайта от всех вредоносных (бот или нет), вы используете SSL. (но если SSL включен, у вас есть риск угона). В противном случае вы можете попробовать js hardcode для обфускации данных формы.
Хорошие ответы выше, плюс все и получить свою собственную идею по этому поводу!
Удачи.
Я читал, что можно поместить форму на 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-соединение для …
Даже если вы попытались поместить блок входа в iframe, который использует https, атака «человек в середине» может легко сменить src этого iframe, так что вы либо сделаете loginbox ссылкой для входа (с страницей входа https), либо вам понадобится больше ресурсов для запуска вашего сайта с помощью ssl для всех веб-страниц, у которых есть окно входа …