Проблема безопасности при передаче сеанса cookie из HTTPS в HTTP

Question

На моем веб-сайте у меня есть несколько страниц HTTPS и несколько страниц HTTP . Когда пользователь входит в систему через HTTPS , файл cookie сохраняется с адресом электронной почты и т. Д. Когда пользователь нажимает на страницу HTTP моего веб-сайта, файл cookie теряется, так как файл cookie был создан в HTTPS . Чтобы решить эту проблему, я добавил этот код PHP в мои страницы HTTP:

session_start();

$currentSessionID = session_id();

Я предполагаю, что это берет cookie, который был сохранен для HTTPS страниц, и просматривает его так, чтобы HTTP мог его увидеть? Это какой-то возможный недостаток безопасности? Я не уверен, что файл cookie действительно передается по HTTP или он просто извлекает то, что браузер уже хранит в временных интернет-файлах ?

Answer 1

Да, , если вы когда-либо устанавливаете идентифицирующие куки-файлы в HTTP-соединении, они могут быть взломаны, а идентифицируемая ими учетная запись может быть взломана .

Отправка файлов cookie сеанса через HTTP (что на самом деле является довольно распространенным делом) - вот что позволяет Firesheep работать. Базовая атака:

1. Пользователь входит в систему через HTTPS (это безопасно).
2. Сервер устанавливает cookie сеанса, чтобы он мог идентифицировать пользователя.
3. Пользователь начинает просматривать страницы по HTTP, что по определению включает отправку сеансового cookie на сервер в незашифрованном виде.
4. Все это действительно распространено. Многие сайты (включая переполнение стека) используют HTTPS только для страниц входа, а затем обслуживают остальную часть сайта по протоколу HTTP. Самое неприятное в том, что злоумышленник в той же сети может прослушивать HTTP-трафик, искать сеансовые куки-файлы и затем использовать их, чтобы выдать себя за пользователя, которого он идентифицирует. Вот что делает Firesheep: вы можете перейти в Starbucks, подключиться к Wi-Fi, включить Firesheep и взломать чужие учетные записи Facebook и Twitter.

Хорошая новость заключается в том, что атака по прослушиванию в сети по большей части не является особенно практической атакой. Единственная причина, по которой Firesheep работает, заключается в том, что у всех во всем мире есть учетная запись Facebook / Twitter / независимо от того, что означает, что когда вы подключитесь к открытому wifi в Starbucks, будут учетные записи для взлома.

Что вы можете сделать?

• Установите для своих файлов cookie «Безопасный», чтобы они отправлялись только по HTTPS.
• Настройте весь сайт для обслуживания по HTTPS и перенаправьте всех аутентифицированных пользователей на ресурсы HTTPS.

Если вы не знаете, что делать, вы можете положиться на тот факт, что подслушивание не является особенно практичной атакой, и поддержка для угона вашего сайта, вероятно, будет реализована только в Firesheep, если ваш сайт действительно популярен; -)

Чтобы ответить на вопрос вашего вопроса немного более прямо: Если ваши HTTP-страницы могут идентифицировать пользователя, то учетная запись этого пользователя может быть взломана, так как сервер должен использовать только куки пользователя .

Answer 2

То, что вы пытаетесь сделать, очень небезопасно и является явным нарушением OWASP A9 .Ни при каких условиях идентификатор сеанса, который аутентифицирован или станет аутентифицированным, не может быть открыт через HTTP.