Как сайты поддерживают безопасные сеансы http (без SSL)?

Question

Я отмечаю, что некоторые сайты (например, gmail) позволяют пользователю проходить аутентификацию через https и затем переключаться на http с незащищенными файлами cookie для основного использования сайта.

Как можно получить доступ к сеансу по протоколу http, но при этом все равно быть безопасным? Или это небезопасно, и поэтому Gmail дает возможность защищать весь сеанс с помощью https?

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

Answer 1

Как сказал Тило, но я объясню немного дальше:)

Веб-сервер не имеет статуса! Это действительно проблема случая аутентификации. Вы не можете просто войти, а затем сказать «с этого момента, этот пользователь вошел в систему» ​​- вам нужно каким-то образом определить, какой именно пользователь запрашивает новый сайт на этот раз.

Обычный способ сделать это - реализовать сеансы. Если при входе в сеть вы перехватываете сетевой трафик, а затем просматриваете сайт, вы обычно замечаете что-то вроде этого:

Вход в систему: вы передадите свое имя пользователя и пароль на сервер. Полностью незашифрованный! (SSL / HTTPS зашифрует этот запрос для вас, чтобы избежать атак «человек посередине»)

Ответ: Вы получите случайно сгенерированную строку из множества странных символов. Обычно они хранятся в файле cookie.

Запрос какого-либо сайта, к которому вы должны иметь доступ только: Вы будете передавать случайно сгенерированную строку на сервер. Сервер будет искать эту строку и видеть, что она связана с вашим сеансом. Это позволяет серверу идентифицировать вас и предоставлять вам доступ к вашим сайтам.

.. Теперь HTTP сам по себе небезопасен. Это означает, что ваш пароль и ваш cookie-файл сессии (случайно сгенерированная строка) будут передаваться в незашифрованном виде. Если кто-то имеет доступ к вашему трафику (через трояны, угон маршрутизатора и т. Д.), Он сможет увидеть ваше имя пользователя / пароль при входе в систему, если вы не используете HTTPS. Это предоставит ему доступ к вашему сайту, пока вы не измените свой пароль (если он не изменит его первым: P). В остальных запросах он сможет получить ваш файл cookie сеанса, а это значит, что он может украсть вашу личность до конца этого жизненного цикла файла cookie («пока вы не выйдете из системы или не истечет время сеанса на сервере).

Если вы хотите чувствовать себя в безопасности, используйте HTTPS. Реально, тем не менее, гораздо проще внедрить кейлоггер в ваш компьютер, чем читать весь ваш трафик:)

(или, как уже отмечали другие, используйте межсайтовый скриптинг для чтения файла cookie вашего сеанса)

Answer 2

Это безопасно только в том случае, если пароль не передается в открытом виде. Можно (и было сделано) перехватить и использовать куки-файл сеанса GMail в режиме HTTP.

Чтобы избежать перехвата сессии, вам нужно оставаться в режиме HTTPS (который, как мне кажется, сейчас предлагает GMail).

Answer 3

Это не совсем возможно и не безопасно. Вот почему мы получили «безопасные куки». Хотя это хорошо против пассивных атак перехвата, потому что имя пользователя / пароль не будут выставлены, однако перехват сеанса все еще возможен.

Также ознакомьтесь с FAQ по безопасности реализации SSL .

Answer 4

Это лишь чуть-чуть более безопасно, чем обычный HTTP - имя пользователя и пароль не передаются по сети в виде открытого текста. Кроме того, он работает точно так же, как обычный сеанс на основе файлов cookie HTTP (потому что так оно и есть); следовательно, все проблемы перехвата сеанса применимы.