Обход аутентификации и атаки на сессии

Сначала об авторизации: вскрытие глазами защитника

Всё ниже предполагает подписанное задание с явным скоупом — намеренно уязвимую лабораторию, CTF, твоё собственное приложение или программу bug bounty с целью в списке активов. Переигрывание или подделка чужой сессии против системы, которой ты не владеешь, в большинстве юрисдикций — несанкционированный доступ, точка; «я использовал только свой токен» перестаёт быть оправданием, как только ты наводишь его на чужой аккаунт. Мы изучаем рассуждение атакующего по одной причине: нельзя надёжно закрыть auth-изъян, который понимаешь лишь как пункт чек-листа. Рабочих токенов, чужих cookie и готовых эксплойтов здесь нет — только механизм, чтобы ты узнал пробел на код-ревью и спроектировал его закрытым до того, как кто-то до него доберётся.

Форма проблемы: где живёт доказательство

Аутентификация и управление сессиями — две разные задачи, которые новички сливают в одну. Аутентификация — одноразовое событие у стены входа: докажи, что ты тот, кем себя называешь, обычно паролем плюс, возможно, вторым фактором. Управление сессией — всё, что после: сервер выдаёт учётку — идентификатор сессии в cookie или самодостаточный токен вроде JWT — и затем доверяет этой учётке как «это тот пользователь, что вошёл» на каждом следующем запросе, потому что сам HTTP не имеет состояния и ничего не помнит.

Эта передача — мягкая цель. Стена входа закалена: лимиты частоты, блокировки, MFA, проверки на утёкшие пароли. А учётка сессии, которую стена производит, — это bearer-токен: кто держит его, того и считают пользователем — и она переигрывается на сотнях запросов, кэшируется в браузерах, иногда логируется, иногда попадает в URL. Атакующий, который никогда не трогает пароль, но получает, предсказывает или фабрикует эту учётку, имеет тот же доступ, что и легитимный пользователь. Три семейства атак целят в этот шов:

• Обход аутентификации — достичь авторизованного состояния, не завершив вход.
• Угон сессии — захватить валидную сессию, принадлежащую кому-то другому.
• Подделка сессии — изготовить учётку, которую сервер ошибочно примет (ловушки JWT).

CSRF — четвёртый ход с подвохом: атакующий вообще не держит учётку — он заставляет собственный браузер жертвы потратить её.

Обход аутентификации: попасть внутрь без стены

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

• Принудительный обход / отсутствие проверок на уровне функций. Форма входа закрывает ссылку на /dashboard, но сам /dashboard никогда заново не проверяет сессию, поэтому прямой запрос к нему входит насквозь. «Аутентификация» была спрятанной дверью, а не замком.
• Логические изъяны в многошаговых потоках. Сброс пароля шлёт токен на почту, но эндпоинт «задать новый пароль» принимает имя пользователя и новый пароль, не привязывая их к валидному, непогашенному, неистёкшему токену — поэтому атакующий сбрасывает любой аккаунт. Или многошаговый вход ставит флаг «прошёл первый фактор», который клиент может перещёлкнуть, минуя MFA.
• Доверие к управляемому клиентом состоянию. Запрос несёт role=admin или isAuthenticated=true в cookie, заголовке или claim’е JWT, который сервер читает, не выводя его заново на своей стороне. Клиент владеет всем, что отправляет; считать любое из этого проверенным фактом — и есть баг.

Зрелый рефлекс — запрет по умолчанию и проверка каждого шага на стороне сервера: каждый защищённый маршрут независимо заново устанавливает, кто вызывающий и что ему можно, вычисляя это из серверного состояния сессии, — никогда не выводя из того, что маршрут стоит «за» страницей входа, и не из значения, присланного клиентом.

Угон сессии: кража валидной учётки

Угон захватывает сессию, которая по-настоящему валидна, — атакующий ничего не подделывает, он получает настоящий bearer-токен. Интересный для защитника вопрос — как токен утекает, потому что у каждого пути утечки есть точный структурный фикс.

Две из них достойны более пристального взгляда. Фиксация сессии переворачивает обычный порядок: вместо кражи токена, который у жертвы уже есть, атакующий даёт жертве id сессии, который сам уже знает (через подготовленную ссылку или подсаженную cookie), ждёт, пока жертва аутентифицируется, и — если сервер сохраняет тот же id через вход — наследует аутентифицированную сессию. Фикс — одна строка дисциплины: ротировать идентификатор сессии при каждом переходе привилегий, чтобы id, под которым жертва аутентифицируется, был новеньким и неизвестным атакующему. HttpOnly и XSS — пара: хранимый XSS, способный выполнить document.cookie, превращает сессию каждого посетителя в кражу, поэтому HttpOnly (cookie невидима для JavaScript) — это локализация, отвязывающая «у нас есть баг XSS» от «баг XSS осушает каждую сессию» — хотя это локализация, а не лечение самого XSS.

Ловушки JWT: подделка учётки, которую сервер примет

JWT — это самодостаточная учётка: claim’ы (кто ты, твоя роль, срок) едут внутри токена, и сервер доверяет им, потому что токен подписан. Этот дизайн переносит границу доверия на подпись — ровно туда, где живут классические подделки. Со стороны атакующего вопрос всегда один: могу ли я заставить сервер принять токен, который я сформировал?

• Ловушка alg: none. Ранние библиотеки JWT уважали заголовок, объявляющий алгоритм none — «этот токен не подписан» — и принимали его как валидный. Атакующий правит payload (например, role: admin), ставит алгоритм none, выбрасывает подпись, и сервер доверяет токену, который он на деле никогда не проверял. Фикс: сервер фиксирует ожидаемый алгоритм; он никогда не даёт заголовку токена выбирать, как его проверять.
• Путаница алгоритмов (RS256 в HS256). Когда проверка использует асимметричный ключ (RS256), публичный ключ по замыслу публичен. Если сервер наивно проверяет тем алгоритмом, что называет заголовок, атакующий переключает заголовок на HS256 (симметричный) и подписывает поддельный токен этим публичным ключом как секретом HMAC — который сервер затем «проверяет» тем же публичным значением. Фикс тот же: фиксировать алгоритм на стороне сервера; никогда не выводить его из управляемого атакующим ввода.
• Слабый или утёкший секрет. Токен HS256, подписанный угадываемым секретом (secret, changeme), брутфорсится офлайн; как только секрет известен, атакующий чеканит любые токены. Фикс: длинные, случайные, управляемые секрет-менеджером ключи — и ротация.
• Игнор exp / нет отзыва. Самодостаточный токен валиден до истечения, и серверного списка для его отзыва нет. Если сервер забывает проверять exp, перехваченный токен годен вечно; даже когда проверяет, украденный токен пригоден до истечения. Фикс: принудительный срок, короткие времена жизни и связка с механизмом refresh/denylist для выхода и отзыва.

CSRF: заставить браузер жертвы потратить учётку

CSRF — изящнейшая, потому что атакующий ничего не крадёт и не подделывает — он эксплуатирует собственную услужливость браузера. Браузер автоматически прикрепляет cookie к любому запросу на сайт, включая запрос, инициированный другим сайтом. Поэтому если жертва залогинена в bank.example и заходит на страницу атакующего, скрытая форма, автоотправляющая POST bank.example/transfer, едет вместе с настоящей cookie сессии жертвы, и банк видит полностью аутентифицированный, безупречно валидный запрос — инициированный атакующим. Сессию не компрометировали; её окружающую власть (ambient authority) позаимствовали.

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

• Анти-CSRF токены — сервер вшивает непредсказуемый, посессионный токен в собственные формы и требует его на запросах, меняющих состояние. Межсайтовая страница атакующего не может прочитать этот токен (политика одного источника блокирует), поэтому не может его вложить, и поддельный запрос отклоняется.
• Cookie SameSite — SameSite=Lax или Strict велит браузеру не слать cookie сессии на межсайтовых запросах вообще, убирая окружающую власть, что и делает CSRF возможным. Lax — сильное недорогое значение по умолчанию; токены остаются ремнём к подтяжкам SameSite.

Заметь связь: CSRF работает именно потому, что легитимная сессия валидна, так что «закали вход» ничего для него не делает. Он защищается на слое приёма запроса, а не на слое аутентификации — ровно поэтому это своя категория.