Session Hijacking — это история, когда у вас всё прошло: логин, пароль, вход, сессия открыта… а доступом к этой сессии пользуется кто-то ещё. При этом сам пароль атакующий может вообще ни разу не видеть. Он просто достаёт идентификатор сессии (Session ID) и подставляет его у себя в браузере или HTTP-клиенте, после чего приложение считает его «тем самым» пользователем.
В вебе сессия — это по сути кусок состояния между запросами: кто вы, что уже сделали, куда имеете доступ. Всё это привязано к уникальному токену, который катается туда‑сюда вместе с запросами. Чаще всего через cookie, иногда — как параметр в URL или в заголовке.
Как воруют Session ID #
Способов много, но суть одна — перехватить или украсть токен:
- подслушивание трафика в публичной Wi‑Fi‑сети, когда запросы идут без шифрования;
- XSS: сайт даёт внедрить чужой JavaScript, тот читает document.cookie и отправляет его злоумышленнику;
- DNS-спуфинг и подмена маршрутов: пользователь думает, что ходит на честный сайт, а на самом деле трафик идёт через машину атакующего;
- отсутствие HTTPS — всё летит по HTTP «как есть», его легко сниффать;
- вредоносные расширения браузера, iframe, прокси посередине, которые могут залезть в cookie или токены из заголовков.
Как только токен оказался у злоумышленника, он подсовывает его в свои запросы — и получает те же права, что и жертва: личный кабинет, переписка, платёжка, всё что было доступно в этой сессии.
Почему это так неприятно #
- пароль вообще может не светиться — нужен только живой Session ID;
- пока сессия живая, её можно перехватить в любой момент до логаута или истечения;
- атакующий может делать любые действия в рамках чужой сессии, как будто это владелец;
- по логам всё выглядит почти нормально — просто ещё один запрос от «того же» пользователя.
Наброски из практики #
- Человек логинится в интернет-банке в кафе через открытый Wi‑Fi. Всё по HTTP. Кто-то запускает сниффер, вытаскивает session cookie и потом спокойно входит в его аккаунт со своего ноутбука.
- На сайте есть XSS. Скрипт, вставленный на страницу, читает cookie из document.cookie и шлёт их на сервер злоумышленника. Дальше — просто подставить токен в свой браузер.
- API передаёт токен в URL, вроде GET /api?token=abc123. Этот URL попадает в логи прокси, аналитики, истории браузера. Токен там висит, пока его кто‑нибудь не подберёт.
Как обычно защищаются #
- везде, где только можно, включать HTTPS: логин, редиректы, API, статика — всё;
- ставить cookie с флагом HttpOnly, чтобы JavaScript к ним не добирался (и XSS-скриптам было нечего красть из document.cookie);
- использовать флаг Secure, чтобы cookie вообще не уходили по нешифрованному HTTP;
- по возможности связывать сессию с окружением — IP, user-agent; но аккуратно, чтобы не ломать жизнь людям за NAT и с мобильными сетями;
- делать сессионные токены максимально короткоживущими, использовать временные токены там, где это уместно;
- нормальный механизм выхода и автоистечения: нажал «выход» — сессия реально умерла, а не болтается ещё сутки;
- дополнительная проверка для критичных операций: смена пароля, перевод денег, изменение прав доступа — просить пароль, код из SMS, что угодно сверх обычной сессии.
Если по-честному, Session Hijacking — одна из тех штук, которые легко недооценить. Пока всё строится вокруг одного токена без контекста и ограничений, его кража превращается в тихую, малозаметную, но очень болезненную историю. При грамотной настройке HTTPS, куков и сессий риск сильно снижается, но как только эти вещи забрасывают — атаки остаются почти невидимыми.
Аренда VPS/VDS — от ₽219/месяц
Почему выбирают VPS от AdminVPS:
✓ Дешевле физического сервера
✓ Более гибкий и мощный, чем обычный хостинг
✓ Бесплатная защита от DDoS и техподдержка 24/7
✓ Масштабируется под любые задачи
Виртуальный сервер VPS/VDS — ваш личный сервер для сайтов, магазинов, ботов и других проектов.
