Насколько безопасно использование сессий в php?

Question

[IvanIF]

После того, как пользователь авторизировался на сайте, я сохраняю в сессию id пользователя, который так же храню в БД. Если пользователь посещает приватные страницы, такие как настройки профиля, уведомления и т.д., я беру из сессии его id и подставляю в sql запрос => если такого id нету, то ничего не вернётся.

Насколько безопасна такая система? Получается, что для того, чтобы получить доступ к чужой приватной информации, нужно всего лишь подставить правильный id в свою сессию. Может ли пользователь вообще это сделать?

Есть ли способы обезопасить такую систему?

Comments

[Максим Федоров]

всего лишь подставить правильный id в свою сессию

Проделайте это **всего лишь** не имея досутпов ни к серверу, ни к аккаунту того, которого вы всего лишь подставить в сессию хотите

[freeExec]

Максим Федоров, представьте, что ID это не какой-то там GUID, а обычный порядковый номер. Я открываю в браузере режим разработчика, прибавляю в куках единичку к своему id и вуаля - я вижу настройки соседнего пользователя.

[IvanIF]

freeExec, речь идёт не о куках, а о сессиях. И на случай, описанный вами, я сохраняю в куках токен из 16 символов. Прибавлять единичку к нему бесполезно )

Answer 1

[granty]

Сессия - это Кука с именем PHPSESSID (по умолчанию, его можно изменить) и значением вида 8jae35cosacp2f5qv6g2uqe6i7. Все данные сессии (массив $_SESSION) хранятся на стороне сервера в файле с именем 8jae35cosacp2f5qv6g2uqe6i7 в формате JSON (можно хранить и в БД).
То есть, вам надо не дописывать 1, а угадывать это имя, что нереально.

У Куки можно установить флаг HttpOnly - такие Куки не видны браузерному коду (яваскрипту), а только отправляются на сервер. Внедрённый на страницу вряжеский яваскрипт не сможет получить доступ к такой Куке.

Куку можно перехватить во время передачи по сети, для защиты от этого есть механизмы:

- установить заголовок HSTS, это заставит браузер работать только по HTTPS, те Кука будет зашифрована при передаче по сети.

- в самой сессии можно хранить IP адрес(привязка сессии к IP). Тогда даже с правильной Кукой не залогиниться, поскольку не совпадет IP (который хранится в $_SESSION на стороне сервера). Неудобно если провайдер меняет IP при каждом переподключении.

- можно в сессии хранить User Agent (все равно Кука - она только для этого браузера). Но при автоматическим апдейте браузера придётся авторизоваться заново, и у кого хватило ума перехватить Куку - перехватит и имя User Agent-а.

- можно в сессии хранить fingerprint браузера (или даже всего компа), только надо придумать как безопасно передавать его на сервер, чтобы сохранять в сессии (и для сравнения при авторизации). Его же тоже могут перехватить.

- при каждой авторизации по Куке, и через каждые ## секунд можно(и нужно) делать session_regenerate_id (меняется 8jae35cosacp2f5qv6g2uqe6i7 на другое), там по ссылке есть пример как это сделать прямо внутри сессии. То есть, угнанная Кука быстро перестаёт работать.

- можно делать "сессионную" Куку (не указывать её время жизни). Такая Кука живёт до закрытия браузера, но после закрытия браузера придётся заново вводить логин/пароль

Можно добавить своей безопасности - например отправлять email пользователю при каждой авторизации по Куке, если не было активности Пользователя более 12 часов.

PS: Если пользоваться сессиями правильно - они достаточно безопасны, практически вся авторизация в интернетах построена на них.

Answer 2

[Максим]

Просмотрев видео ответите на все вопросы.

Answer 3

[Михаил Анискин]

Система достаточно надежна но есть одно НО. Время жизни сессии. Обычно она составляет 1440 секунд. Я реализовал это оставляя куку с идентификатором сессии и временем жизни месяц, при посещении проверял наличие куки и если поменялось то сравнивал пользователя куки если это тот же самый то обновлял эту переменную. Так же реализовал механизм авториризации после гостевого режима с переписыванием корзины на пользователя. Главное это пользователь а сессия вторична.