Верно ли я понимаю безопасный подход к управлению сессиями?

Мануал не читай @ дыры в сайте создавай)

Замечание: Даже при уменьшении риска с помощью session.use_strict_mode атакующий все еще может заставить пользователя использовать уже инициализированную сессию, созданную атакующим. Например JavaScript инъекция. Эта атака может быть смягчена, если следовать рекомендациям этого руководства. Если вы следуете этому руководству, вы должны разрешить session.use_strict_mode, использовать управление сессиями на базе временных меток и перезадавать идентификатор сессии с поможью session_regenerate_id(), как рекомендуется. Если вы все это сделаете, идентификатор сессии атакующего негодяя в итоге будет удален. Если произошел доступ к истекшей сессией, вы должны сохранить все данные активных сессий пользователя. Это позволит для дальнейшего расследования причин произошедшего. После этого, принудительно завершите все активные сессии пользователя и затребуйте у пользователя переавторизации. Это позволит предотвратить атаку с использованием краденной сессии.

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

Алексей Николаев: Я понимаю что такое session.use_strict_mode. Это отлично что вы о нем прочитали, и теперь включите. Я понимаю призыв логировать попытки доступа с левыми sessionid, о которых вы, кстати, не упомянули в стартовом посте.

Я не понимаю что именно дает дублирование(!) информации из сессии в базе, при том что файлы продолжают работать. И вопрос о "сеансе" остается открытым.

Stalker_RED: про сеанс см. комментарий выше, + обновил вопрос

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

Вы сами читали про безопасность сессий? Там эти вопросы освещены. Явно написано:

Вы должны управлять жизненным циклом сессии самостоятельно.

То есть, либо писать свой обработчик для доступа \ хранения к сессиям, либо иные способы.

Алексей Николаев: вы несколько параноите по этому поводу. Не сочтите за грубость. Но давайте представим, как вы таким подходом будете реализовывать сервис "запомнить меня"? Вам в любом случае придётся хранить данные максимальное время у пользователя - а это дыра в безопасности!
Такой подход может быть полезен только, если вы делаете приложение, отвечающее за финансовые операции к примеру(хотя не думаю, что кто-то это будет делать на PHP), в остальных случаях все проблемы перекладываются на пользователя. Вы думаете вашим "клиентам" удобно будет всякий раз проходить муторную авторизацию?

Руслан: > Вам в любом случае придётся хранить данные максимальное время у пользователя
У токена автологина, который должен для этого использоваться, совсем другой уровень безопасности. Его труднее украсть и невозможно угадать, + можно солить его хэшем доступной из PHP конфигурацией системы пользователя.

Руслан: > хотя не думаю, что кто-то это будет делать на PHP
Ну так у пыхи такая репутация исключительно от того, что даже многие "сеньоры" не знают о безопасном управлении сессиями))

Алексей Николаев: В общем-то этот сеанс тоже называется сессией.
пруфы:
https://en.wikipedia.org/wiki/Session_(computer_sc...
https://en.wikipedia.org/wiki/Session_(computer_sc...
Скрин из хрома:
i.imgur.com/bGgsrcQ.png

Итого, что я понял из вашей "схемы"
1. в базе дублируется информация из сессии
2. в базе ведется история смены sessionid
3. контролируется работа сборщика мусора!

Еще и время жизни сессии 5-7 минут. Отошел в туалет - логинься заново.
И все это для того, чтобы засечь попытки авторизоваться с угнанной кукой, верно?
При том что httponly куку передаваемую по https можно угнать двумя способами: расшифровав https трафик или внедрившись в браузер.

Ну, возможно, вы пишете какую-то банковскую систему, но тогда неясно, почему вы задаете вопросы на тостере. Или вы делаете еще один "ужасный сайт™".

Алексей Николаев: Все эти данные в любом случае хранятся на клиенте в том числе и хеш автологина - а хранение на клиенте, по вашему, дыра в безопасности. Единственно, подделать данные несколько сложнее.
Дело не в репутации пыха, просто, как то сложилось, что такие приложения лучше писать на java.)))

Алексей Николаев: Кстати, про время жизни "сеанса" браузера. Я могу неделями не закрывать браузер. Куки с expires=session, соответственно, живут.

Stalker_RED: ну ок, пусть будет сеанс браузера и сессия как сессия PHP. Не суть важно.

> контролируется работа сборщика мусора!
Он работает вероятностно. Может, удалит, а может, не удалит (удалит в другой раз). Что помешает хацкеру воспользоваться неудаленной пока еще сессией, которая должна быть удалена, т.к. пользователь вышел из системы? Необходим контроль за доступом.

> можно угнать двумя способами:
Есть еще социальная инженерия, например. И самое банальное человек залогинился в интернет-кафе, и не закрыл браузер. Кука осталась, а у него на счете 100к, либо персональные данные в аккаунте. Если сессия живет долго, то следующий посетитель сможет войти в его аккаунт.

> Еще и время жизни сессии 5-7 минут. Отошел в туалет - логинься заново.
Повеселило)) Нет, я имел в виду, время ожидания до запрета доступа, если произошел разрыв соединения. Сама сессия может жить больше (час, два), но ее ID меняется с заданной периодичностью - раз в 15 минут, например. То есть пользователь, забывший куку в кафе, будет защищен, если никто не откроет сайт в течение 15 минут.
Плюс можно фоновым js слать поддерживающие запросы. Раз в N минут, как в том же ВК или в Wordpress. Возможно, есть более простые варианты, но это одно из требований безопасности сессий, реализацию которого я вижу только такой.

Давайте так: что вы думаете об этой статье и требованиях, которые там выдвигаются?

Алексей Николаев:
> евремя ожидания до запрета доступа, если произошел разрыв соединения. Сама сессия может жить больше (час, два)

Но ведь соединение обрывается как только загрузка страницы завершена. Я вот отходил на 20 минут и все это время соединение было разорвано.

Статью сейчас почитаю.

Алексей Николаев: В общем ничего нового я там не узнал, кроме пары изменений в php7.
Рекомендации там хорошие, но обратите внимание, что некоторые из них противоречивы, потому что безопасность vs удобство. Там в красненьких таких блоках об этом так и сказано.

Если вы сильно обеспокоены доступом к "протухшим", но еще не удаленным сессиям, можно добавить свою метку времени и проверку в session_handler->read(). Или даже повесить свой удаляльщик файлов сессии на cron, с запуском каждую минуту.

А если уж собрались задействовать базу для сессий, то переносите их туда полностью, зачем вам еще и файлы?

Stalker_RED: с базой я немного переборщил, понемногу пришло понимание, что конкретно имелось в виду в некоторых местах. Но БД нужна, если требуется добавить список сессий с подробной информацией (IP, браузер).

Алексей Николаев: Чаще всего сессии в БД кладут когда бекенд крутится на многих машинах.

Stalker_RED: учту на будущее) спасибо!

А что такое версия пользователя?

Ниже есть объяснение, например порядковый номер действующего пароля