Главная страница » Блог » Cookie Tossing: Когда печеньки — это яд

Cookie Tossing: Когда печеньки — это яд

Mikhail Tarasov
16 февраля, 2026

Cookie Tossing — это атака, где ты, контролируя поддомен (или имея XSS на нём), забрасываешь жертве куку с атрибутом Domain=.target.com. Браузер, тупая железяка, видит две куки с одинаковым именем (твою и легитимную) и отправляет обе. Бэкенд, как правило, парсит только первую попавшуюся. Если первая — твоя, ты переписал реальность для пользователя.

Точка входа: где искать

Что вижу:

Возможность создавать поддомены (SaaS, конструкторы сайтов, учебные порталы).
XSS на любом сабдомене (blog.target.com, dev.target.com).
Отсутствие флага HttpOnly на сессионных куках (не обязательно, но приятно).
Приложение на основном домене (target.com или www.target.com), которое доверяет кукам.

Как поймал:

Поиск контроля: Нашёл XSS на forum.target.com или зарегал attacker.target.com (если сервис позволяет).
Сеттинг бомбы: Исполняем JS: document.cookie="session_id=ATTACKER_SESSION; Domain=.target.com; Path=/;".
Проверка приоритета: Шлёшь запрос к target.com. Если в заголовке Cookie твоя подделка идёт раньше легитимной — бинго.

Чем пахнет: Session Fixation (9/10), CSRF bypass (8/10), Self-XSS to RCE (7/10), DoS аккаунта (10/10).

Че почем: механика хаоса

Браузеры не гарантируют порядок отправки кук, но часто отправляют те, что с более «специфичным» (длинным) путём или доменом. Но если атрибуты совпадают (Domain=.target.com), порядок может зависеть от времени создания. Твоя задача — заставить сервер сожрать твою куку первой.

Эксплойт:

// Payload на захваченном sub.target.com
// Устанавливаем куку для родителя. 
// Важно: перебиваем путь, чтобы быть "специфичнее" или просто спамим
document.cookie = "PHPSESSID=hacker_session_id; Domain=.target.com; Path=/; Max-Age=3600";

// Для верности можно заспамить куку для конкретных путей
document.cookie = "PHPSESSID=hacker_session_id; Domain=.target.com; Path=/admin; Max-Age=3600";

// Редирект жертвы на целевое действие
window.location = "https://target.com/dashboard";

// Payload на захваченном sub.target.com

// Устанавливаем куку для родителя.

// Важно: перебиваем путь, чтобы быть "специфичнее" или просто спамим

document.cookie = "PHPSESSID=hacker_session_id; Domain=.target.com; Path=/; Max-Age=3600";

// Для верности можно заспамить куку для конкретных путей

document.cookie = "PHPSESSID=hacker_session_id; Domain=.target.com; Path=/admin; Max-Age=3600";

// Редирект жертвы на целевое действие

window.location = "https://target.com/dashboard";

Результат в заголовках:

GET /dashboard HTTP/1.1
Host: target.com
Cookie: PHPSESSID=hacker_session_id; PHPSESSID=legit_user_session

GET /dashboard HTTP/1.1

Host: target.com

Cookie: PHPSESSID=hacker_session_id; PHPSESSID=legit_user_session

Сервер (например, на PHP или Node.js) часто парсит куки в объект/массив и берет первое совпадение. В итоге жертва сидит в ТВОЕЙ сессии.

Советы

3 вектора для добивания:

OAuth Hijacking / Login CSRF:
Подбрасываешь свою сессию перед тем, как жертва привязывает Google/GitHub. Жертва логинится в твоём аккаунте. Ты заходишь, видишь привязанную соцсеть жертвы, меняешь пароль — аккаунт твой.
DoS через Cookie Bomb:
Забиваешь браузер мусорными куками для .target.com. Заголовки становятся слишком большими (>4kb или >8kb), сервер отдает 431 Request Header Fields Too Large или 400 Bad Request. Сайт ложится только для конкретного юзера. Лечится только чисткой кук (юзеры тупые, они просто уйдут).
Обход CSRF (Double Submit Cookie):
Если защита основана на сравнении Cookie: csrf_token и POST body: csrf_token. Ты ставишь куку csrf_token=fake через поддомен, и в форме шлёшь csrf_token=fake. Сервер видит совпадение. CSRF пробит.

План атаки:

Захват: Найди любой забытый dev-test.target.com или XSS на help.target.com.
Инъекция: Сформируй ссылку, которая ставит куку и сразу редиректит на target.com/login или target.com/settings.
Фиксация: Если жертва введет пароль или карту, находясь в твоей сессии — ты увидишь это в логах своего аккаунта.
Маскировка: Используй Path=/admin или Path=/api, чтобы перебить куку только там, где нужно, не ломая весь сайт.

Нюанс: Чтобы защититься, админы должны использовать префиксы __Host- в именах кук (например, __Host-session). Такие куки нельзя поставить с поддомена без флага Secure и точного совпадения пути. Если видишь Set-Cookie: session=... без префикса — это твой клиент.