Перехват сессии (session hijacking) — это злоупотребление действующим идентификатором сеанса, при котором сервис принимает атакующего за уже аутентифицированного пользователя. Пароль атакующий может так и не узнать: владения активным токеном бывает достаточно, пока сервис не завершит его срок, не заменит или не отзовёт его.

Ключевые выводы

Аутентификация подтверждает личность при входе, а токен сессии переносит этот результат на последующие запросы.

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

Смена пароля не всегда отзывает существующие сеансы, поэтому важна явная инвалидация сеансов.

HTTPS и безопасные параметры Cookie защищают важные пути, но сами по себе не устраняют XSS, вредоносные расширения или вредоносное ПО на устройстве.

Общая модель защиты аккаунтов, устройств и сети описана в руководстве по онлайн-безопасности.

Как происходит перехват сессии?

HTTP-запросы независимы друг от друга, поэтому веб-сервису нужен способ запомнить, что браузер уже прошёл аутентификацию. Он выдаёт идентификатор сеанса — часто в виде Cookie, — и браузер предъявляет его с последующими запросами. OWASP отмечает, что аутентифицированный токен сессии временно равнозначен способу аутентификации, с помощью которого он был создан.［1］ NIST описывает соответствующий сеансовый секрет как значение, которое со временем связывает программу пользователя с сервисом.［2］

Обычная цепочка атаки выглядит так:

Пользователь проходит аутентификацию и получает токен сессии.
Атакующий получает, предсказывает, внедряет или иным образом контролирует действующий токен.
Атакующий отправляет этот токен сервису.
Сервис находит действующий сеанс и применяет права доступа жертвы.
Атакующий пользуется аккаунтом, пока токен не будет отклонён, не истечёт, не будет заменён или отозван.

Поэтому граница защиты проходит не только через страницу входа. Важны создание сеанса, его хранение, передача, ротация, срок действия и отзыв.

Надёжная архитектура также отделяет непрерывность сеанса от актуальности авторизации. Токен, действительный в момент выдачи, не должен незаметно сохранять доступ после удаления роли, блокировки аккаунта или смены чувствительного фактора. Сервис может заново проверять важное состояние авторизации и требовать недавней аутентификации для действий с серьёзными последствиями, а не считать каждый активный сеанс одинаково надёжным навсегда.

Откуда берётся украденный токен сессии?

Метод	Что происходит	Основная защита
Раскрытие или перехват токена	Действующий идентификатор утекает через трафик, журналы, URL, заголовок Referer или небезопасное хранилище	HTTPS, защищённая передача, отсутствие токенов в URL, безопасное хранение
Фиксация сессии	Атакующий заставляет жертву пройти аутентификацию с уже известным ему идентификатором	Отклонять не выданные сервисом ID и создавать новый после входа
Кража или действия через XSS	Вредоносный скрипт читает доступный токен или действует через браузер жертвы	Защита от XSS, HttpOnly, изоляция контента, повторная аутентификация
Вредоносное расширение или ПО	Программа на устройстве читает данные браузера или управляет запросами	Доверенное ПО, минимальные права, очистка устройства
Предсказание или перебор токена	Слабые или короткие идентификаторы подбираются	Криптографически случайные токены с высокой энтропией и обнаружение подбора

OWASP относит раскрытие, перехват, предсказание, перебор и фиксацию к путям, которые могут привести к выдаче себя за пользователя. Методы различаются, поэтому одна защитная мера не может закрыть их все.

Чем токен отличается от украденного пароля?

Свойство	Пароль или passkey	Токен сессии
Назначение	Подтверждает личность при аутентификации	Представляет уже подтверждённое состояние после входа
Типичный срок жизни	Долго, до смены или отзыва	Обычно ограничен тайм-аутом простоя и абсолютным сроком
Повторное использование	Может создавать новые сеансы	Напрямую продолжает существующий сеанс
Лучшая первая мера	Сменить или восстановить учётные данные и проверить факторы	Отозвать сеансы и токены, затем защитить учётные данные

Украденный пароль позволяет атакующему выполнить новый вход, если его не остановят другие меры защиты. Украденный токен сессии может обойти этап входа, потому что сервис видит уже установленный сеанс. Это же объясняет, почему MFA может заблокировать новый вход по паролю, но не нейтрализует автоматически токен, украденный после успешной MFA.

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

Это то же самое, что MITM или XSS?

Нет. Перехват сессии — это результат: несанкционированное использование чужого сеанса. MITM-атака, уязвимость XSS, вредоносное расширение, небезопасный журнал или заражение вредоносным ПО могут быть лишь одним из путей к токену.

OWASP указывает, что TLS защищает идентификаторы сеанса от перехвата в сети, но не от предсказания токена, перебора, подмены на стороне клиента или фиксации. HttpOnly может помешать обычному скрипту прочитать Cookie, однако вредоносный скрипт всё ещё способен выполнять аутентифицированные действия из браузера жертвы. Модель угроз должна называть и источник раскрытия токена, и поведение сервиса, который его принимает.

Почему смена пароля может не завершить перехват?

Пароль и база сеансов — это разное состояние. Одни сервисы при смене пароля уничтожают все сеансы, другие отзывают только выбранные, сохраняют доверенные устройства или требуют, чтобы пользователь сам выбрал «выйти везде».

OWASP рекомендует создавать новый идентификатор сеанса после аутентификации и изменения привилегий, уничтожать старые идентификаторы и при необходимости инвалидировать сеансы. NIST требует, чтобы выход и тайм-ауты инвалидировали привязку сеанса, но реализует эти меры каждый сервис по-своему. Поэтому при компрометации пользователю нужно и сменить раскрытые учётные данные, и явно отозвать неизвестные или все сеансы.

Что делать пользователю?

Откройте сервис через официальное приложение или вручную введённый адрес на доверенном устройстве.
Просмотрите активные сеансы, устройства, события безопасности и недавнюю активность в аккаунте.
Отзовите неизвестный сеанс или выйдите на всех устройствах, если принадлежность неясна.
Смените пароль, если он мог быть раскрыт; удалите неизвестные способы MFA и восстановления.
Удалите подозрительные расширения браузера, обновите устройство и проверьте его на вредоносное ПО.
Проверьте пересылку почты, сторонние разрешения, изменения платёжных данных, файлы и сообщения.
Заново пройдите аутентификацию в чувствительных сервисах и обратитесь к провайдеру, если управление сеансами недоступно.

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

Как сервисам предотвращать перехват сессии?

Сервисам нужна эшелонированная защита:

генерировать непредсказуемые идентификаторы сеанса с достаточной энтропией;
принимать идентификаторы только через предусмотренный механизм, обычно через защищённые Cookie;
использовать HTTPS на протяжении всего сеанса и задавать атрибуты Secure, HttpOnly и подходящий SameSite;
создавать новые идентификаторы после входа и изменения привилегий;
применять тайм-аут простоя, абсолютный срок и завершение сеанса с учётом риска;
показывать понятную историю устройств и сеансов и давать надёжную функцию выхода со всех сеансов;
требовать повторной аутентификации для рискованных изменений и платежей;
обнаруживать повторное использование токена, резкую смену клиента, невозможное поведение и необычные действия в аккаунте, не считая местоположение по IP точным подтверждением личности;
предотвращать XSS и не допускать попадания чувствительных токенов в URL, историю браузера, журналы и небезопасное хранилище.

NIST требует защищённых каналов, инвалидации при выходе и ограничений по времени для сеансовых секретов, а также не рекомендует небезопасное хранилище браузера. OWASP дополняет это практическими мерами для Cookie, обновления и срока действия идентификаторов, обнаружения аномалий и защиты от фиксации.

Сигналы риска должны запускать соразмерные меры, а не автоматически делать выводы о личности. Новый IP-адрес может появиться из-за поездки, мобильного оператора или VPN; одновременное появление токена у несовместимых клиентов, за которым следуют изменения восстановления или платёжных данных, — более сильное доказательство. Хорошая система хранит достаточно истории событий, чтобы пользователь и поддержка могли отозвать доступ, не раскрывая сам токен.

Итоги

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

Часто задаваемые вопросы (FAQ)

Возможен ли перехват без пароля?

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

Защищает ли MFA?

MFA защищает аутентификацию и затрудняет новые входы. Она не защищает автоматически токен, украденный после прохождения MFA, поэтому хранение, передача, срок действия и отзыв сеансов по-прежнему важны.

Поможет ли выход?

При правильной реализации выход должен инвалидировать соответствующий сеанс на сервере. Выход только на одном локальном устройстве может не отозвать другие сеансы, поэтому используйте управление сеансами аккаунта или функцию «выйти везде».

Очистка Cookie отзывает токен?

Она удаляет локальные Cookie браузера и может завершить сеанс в этом браузере. Скопированный токен может оставаться действительным в другом месте, пока сервис не инвалидирует его или не истечёт его срок.

Что такое фиксация сессии?

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

HTTPS предотвращает все атаки?

Нет. При правильном использовании HTTPS защищает токены при передаче от сетевого перехвата. Он не останавливает XSS, вредоносные расширения, вредоносное ПО, предсказание токенов, небезопасные журналы или ошибки отзыва.

Все сеансовые Cookie опасны?

Нет. Cookie — стандартный способ поддерживать сеанс. Риск зависит от того, как идентификатор создаётся, ограничивается по области действия, передаётся, хранится, истекает и инвалидируется.

Как заметить перехват?

Ищите неизвестные активные сеансы, действия, которых вы не совершали, изменённые настройки безопасности или одновременное использование, которое нельзя объяснить. Одно лишь местоположение ничего не доказывает; проверяйте активность в официальном аккаунте и отзывайте сомнительные сеансы.

Отказ от ответственности: Материал носит общеобразовательный характер и не заменяет юридическую, экспертную или профессиональную помощь при инциденте.

Источники

OWASP Cheat Sheet Series — Session Management Cheat Sheet — https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html
NIST SP 800-63B-4 — Session Management and Session Bindings — https://pages.nist.gov/800-63-4/sp800-63b.html

Sources checked 4 октября 2026 г.

Рекомендуемые статьи:

Что такое перехват сессии?