Логин должен быть https - PullRequest
       6

Логин должен быть https

32 голосов
/ 30 ноября 2010

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

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

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

Ответы [ 8 ]

30 голосов
/ 30 ноября 2010

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

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

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

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

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

7 голосов
/ 30 ноября 2010

Простой ответ «Да», ваша страница входа и остальные сайты должны обслуживаться по SSL

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

4 голосов
/ 08 декабря 2010

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

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

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

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

3 голосов
/ 30 ноября 2010

Если вы хотите, чтобы ваши данные были в безопасности, вы должны использовать SSL (сертифицированный) на всем сайте.Но вам не нужно иметь SSL, чтобы сохранить ваши пароли в безопасности.Вы можете, например, использовать openID, Facebook Connect, Twitter, чтобы обработать эту часть для вас.Таким образом, пароли никогда не передаются по сети в виде простого текста.

1 голос
/ 10 декабря 2010

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

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

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

Удачи.

1 голос
/ 09 декабря 2010

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

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

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

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

0 голосов
/ 07 декабря 2010

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

0 голосов
/ 30 ноября 2010

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

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

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

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

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

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

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

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

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

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