Недавно я подумал о том, как такие веб-сайты, как gmail и amazon, используют HTTPS во время входа в систему при доступе к вашей учетной записи. Это, очевидно, имеет смысл, поскольку вы вводите имя пользователя и пароль своей учетной записи и хотите, чтобы это было безопасно. Однако на Facebook, среди множества других веб-сайтов, их вход в систему осуществляется с помощью простого HTTP. Разве это не значит, что мое имя пользователя и пароль полностью не зашифрованы? Что, что еще хуже, означает, что все те люди, которые заходят в свои facebook (или аналогичные сайты) через точку доступа Wi-Fi публично, восприимчивы к тому, что кто-то получает свои учетные данные с помощью простого анализатора пакетов (или чего-то подобного)? Неужели это так просто? Или я неправильно понимаю безопасность в Интернете?
Я инженер-программист, работающий над некоторыми вещами, связанными с Интернетом, и хотя в настоящее время я не слишком вовлечен в аспект безопасности нашего программного обеспечения, я знал, что, вероятно, мне следует знать ответ на этот вопрос, поскольку он чрезвычайно важен для безопасность сайта.
Спасибо!
Да. Все, что делается через открытый Wi-Fi с использованием HTTP, полностью открыто для перехвата, воспроизведения и т. Д.
Тем не менее, сайты, которые используют HTTPS для согласования входа в систему, но обмениваются полученным файлом cookie аутентификации через HTTP, также очень открыты для захвата сеанса, поскольку разработчик пожарная овца показал.
Если вам нужна достойная безопасность, делайте все под прикрытием HTTPS. Серверы теперь достаточно быстры, а сертификаты SSL достаточно дешевы (если вы присматриваетесь), что практично; веб-разработчикам больше нет оправдания, подвергая опасности своих пользователей.
Если вы действительно входите на сайт с помощью простого HTTP, это совершенно небезопасно, да, и любой в общедоступной WLAN может обнюхать ваши данные. Вот почему, например, Facebook выполняет фактический вход через HTTPS (посмотрите исходный код стартовой страницы Facebook, и вы увидите его), а затем продолжите работу без шифрования, чтобы сэкономить на вычислительной мощности. Это, по крайней мере, защищает ваш пароль, но по-прежнему допускает любые другие атаки, такие как захват сеанса (они обнюхивают ваш файл cookie сеанса и сами его используют).
Сайты, передающие конфиденциальные данные (например, учетные данные или файлы cookie, которые действуют как прокси для учетных данных) в открытом виде, подвергают своих пользователей риску. Для сбора этих учетных данных подойдет любой метод, который можно использовать для перехвата и записи трафика (снифферы, сетевые адаптеры Wi-Fi в режиме мониторинга и т. Д.). Сеансы могут быть перехвачены, ответы удаленных серверов могут быть подделаны и т. Д. Всевозможные неприятности возникают из-за того, что данные передаются в открытом виде.
Недостаточно просто перемещать учетные данные пользователей через HTTPS. Если вы используете файлы cookie, которые заменяют учетные данные пользователя, вы также не можете переместить их через HTTP, иначе вы рискуете скомпрометировать сеанс пользователя.
Как разработчик, вы оказываете своим пользователям медвежью услугу, если не используете HTTPS для перемещения их учетных данных. Обычно это означает более высокую загрузку ЦП на каком-то уровне вашей инфраструктуры и непрозрачность трафика по мере его продвижения к границе вашей сети. Это означает создание программной архитектуры, которая позволяет доставлять «массовый» контент (статические изображения, статические сценарии и т. Д.) В виде открытого текста, но доставляет персонализированный контент (то есть контент, состав которого контролируется путем получения учетных данных от удаленного пользователя. ) через средства, обеспечивающие безопасную передачу учетных данных.