Gmail и Facebook HTTPS, специфичные для профиля: уязвимы? - PullRequest
2 голосов
/ 19 февраля 2011

Я начал задумываться о чем-то:

Учитывая, что Gmail и Facebook используют HTTPS для каждого профиля и не используют его по умолчанию, уязвимы ли подключения к ним?

Я совсем не знаком с задействованными протоколами, но мои рассуждения сводятся к следующему: браузер должен выяснить, использовать ли HTTPS или нет, и по умолчанию это не так.Это означает, что всякий раз, когда я указываю свою страницу на Facebook.com, мой браузер отправляет некоторую информацию (возможно, идентификатор сеанса?) По каналу незашифрованный в Facebook, до , чтобы выяснить,или нет, я просил HTTPS.(Пожалуйста, исправьте меня, если я ошибаюсь, но я не верю, что для отправки этого используется безопасное соединение.)

Разве это не означает, что кто-то может взломать идентификатор сеанса в середине небезопасногосвязь?Это потенциальная уязвимость?

Ответы [ 2 ]

3 голосов
/ 19 февраля 2011

Файлы cookie, использующие флаг безопасности, отправляются только через HTTPS. Таким образом, можно всегда перенаправлять HTTP на HTTPS и избегать отправки файлов cookie сеанса по HTTP до перенаправления, но я бы не стал рассчитывать на это, поэтому никогда не подключался бы к Gmail, используя http://mail.google.com/ - только https://mail.google.com/

На самом деле я только что проверил, и Gmail, похоже, установил 6 файлов cookie, только 3 из которых являются безопасными. Когда вы посещаете http://mail.google.com/mail/, ваш браузер отправляет ваш адрес электронной почты в открытом виде, чтобы все могли его увидеть, прежде чем вы будете перенаправлены на HTTPS.

Что касается безопасности Facebook ... Я рекомендую посмотреть выступления Сами Камкара "Как я встретил вашу подругу" в Defcon (короче) и в Blackhat (больше) .

Обновление, чтобы избежать путаницы в комментариях: Сами Камкар объяснил способ догадаться куки-файла сеанса Facebook, поэтому HTTPS здесь не имеет никакого значения. Дело в том, что вы можете использовать только HTTPS и при этом оставаться уязвимым для перехвата сеанса.

2 голосов
/ 19 февраля 2011

Оба они безопасны и не предоставляют идентификаторы сеанса

  1. Пользователь просматривает http://www.facebook.com
  2. Пользователь вводит имя пользователя и пароль, который отправляет https://www.facebook.com/...
  3. Серверы facebook безопасно получили имя пользователя / пароль на шаге 2, проверит пользователя и проверит базу данных, чтобы узнать, запрашивает ли этот пользователь трафик только по SSL.Если у пользователя выбран только трафик SSL, Facebook устанавливает безопасный бит в куки, который содержит идентификатор сеанса пользователя, позволяя отправлять его только через безопасные соединения.Все ссылки, которые Facebook возвращает этому пользователю, являются https: // ссылками, поэтому каждое соединение зашифровано.

    Нигде в этом процессе не отображается идентификатор сеанса

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