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

Question

[Алексей Николаев]

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

Я понимаю это следующим образом (само собой, strict_mode для сессий включен):
- создается таблица sessions, туда пишется каждая сессия залогиненного пользователя, ассоциированная с ним, + время ее создания.
- если произошел разрыв связи, сеанс нарушен, ждем 5-7 минут перед тем, как пометить сессию неактивной, если пользователь появляется в это время, восстанавливаем сессию
- сессионные cookie живут только один сеанс (имеется в виду сеанс работы браузера), собственно сессии на сервере живут как можно меньшее время
- id сессии меняется каждые 15-30 минут в течение сеанса, пишется в БД, старые ID помечаются как неактивные
- сессии, помеченные неактивными, удаляются из БД только если файл сессии удален сборщиком мусора
- соответственно, пресекаем попытки постучаться с сессией, которая уже есть в БД и помечена как неактивная
- так же пресекаем попытки постучаться с сессией, которой в БД нет (если все новые ID создаются сервером, это наверняка атака)

Корректен ли такой подход к управлению сессиями, или я что-то упустил \ неверно понял?
Заранее спасибо.

Answer 1

[Stalker_RED]

Мануал не читай @ велосипед изобретай!

Все сессии и так имеют метку с временем последнего доступа. Время создания тоже можно запомнить, но зачем?
Сессии и так можно хранить в базе.
Вы и так можете менять sessionid.
Время жизни сессии и так настраивается.

Впрочем, допустим, вы изобрели что-то новое. Расскажите подробнее что такое, по вашему, сеанс связи, и что значит "все сессии живут только один сеанс".

Comments

[Алексей Николаев]

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

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

[Алексей Николаев]

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

[Stalker_RED]

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

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

[Алексей Николаев]

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

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

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

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

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

[Руслан Полин]

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

[Алексей Николаев]

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

[Алексей Николаев]

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

[Stalker_RED]

Алексей Николаев: В общем-то этот сеанс тоже называется сессией.
пруфы:
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.)))

[Stalker_RED]

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

[Алексей Николаев]

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

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

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

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

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

[Stalker_RED]

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

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

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

[Stalker_RED]

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

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

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

[Алексей Николаев]

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

[Stalker_RED]

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

[Алексей Николаев]

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

Answer 2

[Александр Аксентьев]

Почти всё что описали и так стандартная работа сессий.
К безопасности это добавляет примерно ничего.

Если вам нужна защита конкретно от угона сессий(хотя 99% сайтов работают и без этого,т.к. никому не упали).
Нужно в коде делать проверку по IP и/или браузеру(useragent).
И опять же это всё на сам механизм сессий-то никак не влияет. Тупо в той же сессии хранить хеш ip/браузера и в случае несовпадения сессию "разлогинивать" из под пользователя, удалять её нигде и чистить не надо, всё уже сделано за вас.
Кроме этого защиты ничего не прибавит.

Answer 3

[Владимир Дубровин]

Есть альтернативный способ, не требующий хранения сессий - генерировать случайный идентификатор добавлять id пользователя, временную метку и подпись сервера (например hash(session+id_пользователя +версия_пользователя+timestamp+secret), на получении запроса - проверять подпись сервера, периодически обновлять сессию со свежим таймстампом при активности пользователя, выдавать ему новую со свежим таймстампом. Версия пользователя нужна чтобы иметь возможность принудительно терминировать сессии пользователя, например при смене пароля.

Comments

[koller18]

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

[Владимир Дубровин]

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