Сессия и токен сессии: как сайт понимает, что это снова вы

Веб-запросы по своей природе независимы: сервер получает запрос, отдаёт ответ и «забывает» о собеседнике. Но на практике вы вводите пароль один раз и потом свободно ходите по разделам кабинета. Эту иллюзию непрерывности создаёт сессия — договорённость между браузером и сервером, что все последующие запросы принадлежат тому, кто прошёл вход.

Механика проста. После успешного входа сервер создаёт запись о сеансе и выдаёт браузеру случайную длинную строку — токен сессии. Браузер прикладывает её к каждому следующему запросу, чаще всего в cookie, а сервер по строке находит нужную запись.

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

В другой схеме токен сам содержит сведения о пользователе и подписан сервером, а хранилище сеансов не нужно. Так работает подход с подписанными токенами, о которых подробнее рассказано на странице про JWT. Плюс такого варианта — масштабируемость, минус — сложность немедленного отзыва: токен остаётся действительным до окончания срока.

У сеанса обычно есть сразу два ограничения времени. Простой (idle timeout) означает, что сеанс завершается, если вы давно ничего не делали, и типичен для банковских кабинетов, где через несколько минут просят войти заново. Абсолютный срок ограничивает общую длительность сеанса независимо от активности: через определённое время даже активному пользователю предлагают подтвердить вход.

Галочка «запомнить меня» устроена иначе. Она создаёт отдельную долгоживущую cookie, по которой сайт может открыть новый сеанс, и потому эту cookie защищают особенно тщательно, а часто привязывают к устройству. Если вы работаете на общем компьютере, от этой галочки лучше отказаться. Заодно после смены пароля разумные сервисы завершают все прежние сеансы; если ваш этого не делает, проверьте список устройств вручную.

Токен — как ключ от квартиры: кто им владеет, тот и «хозяин». Если злоумышленник получил вашу строку, ему не нужен пароль. Пути получения разные: скрипт, внедрённый через уязвимость XSS, перехват в незащищённой сети, вредоносная программа на устройстве, утечка в журналах или в адресной строке.

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

Хорошая практика включает несколько мер. Cookie получают флаг HttpOnly, чтобы скрипты страницы не могли её прочитать, флаг Secure, чтобы она уходила только по HTTPS, и атрибут SameSite, который ограничивает отправку при переходах с других сайтов и помогает против CSRF. Срок жизни делают ограниченным, а для чувствительных действий, например смены пароля, требуют повторного подтверждения.

Также полезны привязка к признакам устройства, уведомления о новых входах и возможность просмотреть и завершить активные сеансы.

В браузере откройте панель разработчика и найдите раздел с cookie сайта: там видны имя, срок и флаги. Не копируйте значения и никому их не показывайте. В настройках почты и соцсетей обычно есть список устройств и сеансов; незнакомые стоит завершить и сменить пароль.

При работе на чужом компьютере выходите из аккаунта явно, а не просто закрываете вкладку. И не отправляйте скриншоты панели разработчика: они могут содержать ключи доступа.

Разработчикам стоит помнить о хранении токенов на стороне браузера. Хранилище браузера, доступное скриптам, уязвимо к XSS, тогда как cookie с флагом HttpOnly скриптам не видна. Выбор места хранения зависит от архитектуры, но компромиссы нужно осознавать и подбирать защиту под них, включая короткий срок жизни и обновление токена.