Уважаемые пользователи, подскажите как можно максимально защитить сессию от воровства (подмены)?
На данный момент использую:
1. Шифрование сессии SHA512
2. Привязку к хешу md5 связки IP + USER_AGENT, и каждый раз проверяю на соответствие.
3. Динамический идентификатор сессии. С каждым запросом к серверу создается новая сессия сохраняя при этом данные с предыдущей. Таким образом даже если злоумышленник сворует куки, подменит IP и USER_AGENT то есть шанс что он не успеет зайти. При условии что после кражи сессии пользователь сделал хотя бы один запрос.
Что можно еще добавить, или наоборот убрать? Заранее спасибо! :)
Обычно в куках хранится идентификатор сессии с ключом вида PHPSESSID
Но можно сделать так, чтобы само имя куки было менее предсказуемым, например md5(идентификатор-сервиса)
Можно, рассматривал данный вариант, но особо это не усложнит. Да и во-первых: уже используется динамическая сессия и свою эффективность теряет данный способ. И во-вторых: некоторые браузеры могут отвергать случайные куки. Со странными названиями и т.д.
Хотя, если быть честным, то еще думаю над этим вариантом. Спасибо! :)
А вот IP + USER_AGENT, вы создаете проблему для пользователей из сотовых сетей, так как у них IP адрес может меняться.
Шифрование ключа сессии бессмысленно, ведь это всего лишь данные которые можно скопировать.
Динамический токен поможет выявить одновременную работу, но не защитит от угона на 100%
IP я все же не буду использовать, но USER_AGENT оставлю. Пусть это и HTTP_, и изменить его не составит труда, но все же некий дополнительный % защиты. Да и не совсем динамический токен у меня. Просто сессия пересоздаеться каждый раз. Еще сделаю анализ на нагрузку, и может все же лучше урезить частоту пересоздания. Посмотрим. А так, если какая-то шпион-программа стырит куки, юзер_агент, и отправит куда-то, то есть немалый шанс что злоумышленник просто не успеет "втиснуться."
Дмитрий Онацкий: Сценарий атаки: 1. Получаем id сессии и USER_AGENT 2. Устанавливаем соединение 3. Сервер возращает новый id сессии. При таком подходе добропорядочный пользователь не сможет подключиться, но до его попытки вы даже не узнаете, что была угнана сессия
Петр: Немного не все так просто, во втором пункте есть нюанс, нужно установить соединение быстрее чем пользователь.
Ну а от про то что не узнаю угнана сессия немного не понял. Узнать то можно, есть как минимум два способа. Первый, это отслеживать подозрительную смену IP. И второй, после того как пользователь не смог подключиться - можно это уловить и отправить отчет что мол с таким-то юзером такая-от проблемка.
Но это я так думаю) А там черт его)
Петр: Создать дополнительную куку что мол auth статус я имею и все ок. Но так как плохыш украл сессию и подключился, то наше подключение прерывается. И в основной сессии мы имели статус auth. И просто проверить на наличие auth-статуса и там и там. Если лишь дополнительной куке такой статус. То был сбос подключения. И все. Не особо сложно.
Средний
