Тестирование JWT и авторизации
Анализ JWT, токены alg=none и RS-to-HS, HMAC-словарь, A/B replay учётных данных.
Traffic Jam собирает все учётные данные, обнаруженные в импортированных захватах, на вкладке Auth рабочего пространства API, декодирует и проверяет JWT офлайн в отдельном верстаке, а также выполняет replay одного запроса от лица нескольких наблюдаемых идентичностей для исследования BOLA/IDOR. Всё это выполняется локально над захватами, которые у вас уже есть; используйте только на системах, которые вам разрешено тестировать.
Извлечение материалов авторизации из захватов
Откройте рабочее пространство API и переключитесь на вкладку Auth. Traffic Jam сканирует все видимые сессии и группирует сигналы, несущие учётные данные, по имени:
| Вид сигнала | Источник |
|---|---|
| Authorization | Заголовок запроса Authorization (включая Bearer-токены) |
| Cookie | Отдельные пары запросов Cookie, разобранные по имени cookie |
| Set-Cookie | Заголовки ответа Set-Cookie, разобранные по имени cookie |
| Query parameter | Чувствительные имена в query-строке (токены, ключи, идентификаторы сессий) |
| Custom | Прочие заголовки запроса с чувствительными именами |
Карточка каждой группы показывает общее число использований, количество уникальных значений и число эндпоинтов. Разверните группу, чтобы увидеть все варианты значений вместе с эндпоинтами, на которых они встречались, и кнопками Sample, которые переходят к запросу, несущему данное значение. Значения по умолчанию замаскированы; включите переключатель отображения значений в рабочем пространстве, чтобы увидеть точные значения и разблокировать действия Copy и Audit. Значения Authorization: Bearer eyJ… декодируются прямо на месте, с краткой сводкой payload (iss, sub, aud, exp, iat, nbf, jti, scope, client_id; временные метки отображаются как даты в формате ISO).
[!NOTE] Извлечение пассивно: оно только читает импортированные захваты. Ничего не отправляется на сервер, пока вы явно не запустите replay.
Аудит JWT
Когда секреты раскрыты, нажмите Audit на любом декодированном варианте JWT, чтобы открыть верстак безопасности JWT. Верстак декодирует header и payload, сообщает алгоритм и отображает статус срока действия в виде бейджа: valid, expired, not-yet-valid или no-expiry.
Анализ выдаёт предупреждения о состояниях, имеющих значение при пентесте:
alg: none— токен не подписан.- Любой алгоритм
HS*— секреты HMAC поддаются офлайн-взлому, а если сервис также принимает RS256, может быть применима атака путём подмены алгоритма (alg-confusion). - В header не объявлен
alg. - Отсутствует claim
exp— токен сам по себе никогда не истекает. - Время жизни более 24 часов (
exp - iat) — сообщается как долгоживущий токен, в часах. expне позжеiat— неположительное время жизни.- Пустой сегмент подписи.
- Чувствительные claim в payload:
password,passwd,secret,ssn,credit_card,creditcard,card_number,private_key.
Офлайн-проверка HMAC по словарю
В разделе верстака HMAC dictionary check вставьте кандидатов по одному на строку и нажмите Test candidates. Проверка работает только для токенов HS256, HS384 и HS512: каждый кандидат подписывается HMAC поверх header.payload с помощью WebCrypto внутри рендерера, и кандидат, воспроизводящий захваченную подпись, сообщается как восстановленный секрет. Ничего не покидает рендерер; прогресс сообщается каждые 50 кандидатов. Диалог поставляется с небольшим стартовым списком (secret, password, password123, changeme, JWT_SECRET) — замените его словарём, подходящим для цели.
Генерация тестовых токенов alg=none и RS-to-HS
Верстак собирает два классических зонда для атак на путаницу алгоритмов. Оба — только для копирования: диалог ничего не отправляет, поэтому вы сами решаете, куда попадёт зонд (например, вставив его в верстак replay — см. /docs/ru/replay/workbench/).
- Вариант alg=none — нажмите Copy alg=none variant. Header переписывается на
alg: "none", а сегмент подписи опустошается (header.payload.). Отправьте его, чтобы проверить, принимает ли верификатор неподписанный токен. - Подмена RS256 → HS256 — вставьте RSA-публичный ключ сервера (PEM) в поле RS256 → HS256 confusion variant и нажмите Generate & copy. Header токена переписывается на
HS256и переподписывается HMAC с использованием текста публичного ключа в качестве ключевого материала. Если сервер верифицирует HS256-токен по своему RSA-публичному ключу, поддельная подпись пройдёт проверку.
[!WARNING] Эти зонды изменяют материалы аутентификации и могут инвалидировать сессии или срабатывать антифрод-контроли. Отправляйте их только на цели, на тестирование которых у вас есть письменное разрешение.
A/B replay учётных данных (BOLA/IDOR)
Когда в группе есть два или более уникальных значений (например, session cookie двух пользователей, захваченные в разных сессиях), разверните её и нажмите Test variants for BOLA/IDOR. Диалог Credential variant A/B test выполняет replay одного представительного запроса по разу на каждое наблюдаемое значение учётных данных и выстраивает ответы рядом для сравнения.
- Диалог выбирает представительный запрос из наблюдаемых запросов группы, отдавая предпочтение
GET/HEAD. Исходный URL и тело никогда не изменяются — подменяются только учётные данные. - Нажмите Run A/B test. Каждый вариант воспроизводится последовательно (до 20 вариантов, таймаут 30 с на запрос) через тот же batch-эндпоинт, что обеспечивает массовый replay и который применяет серверный лимит в 50 элементов.
- Результаты помечаются A, B, C… с замаскированным значением, актуальным статусом и длительностью, а также вердиктом сравнения «захваченное против живого». Похожие успешные тела у разных идентичностей говорят о том, что эндпоинт не привязывает ресурс к вызывающей стороне — кандидат на BOLA/IDOR.
Для групп cookie заменяется только целевое имя cookie; остальная часть захваченного заголовка Cookie сохраняется. Если представительный метод изменяет состояние (всё, кроме GET, HEAD, OPTIONS, TRACE), перед запуском необходимо установить флажок Confirm state-changing replay.
[!TIP] Группы query-параметров нельзя протестировать в режиме A/B из этого диалога — механизм переопределения подменяет заголовки, а не URL. Такие запросы воспроизводите вручную из /docs/ru/replay/workbench/.
Реконструкция потоков аутентификации
Вкладка Security рабочего пространства API содержит раздел Credential lifecycles, построенный по выдаче Set-Cookie и последующему использованию в запросах по всем сессиям. Каждый поток связывает учётные данные (замаскированные) с ответом, который их выдал, и вплоть до 20 запросов, которые их воспроизводили, с сортировкой от наиболее переиспользуемых. Потоки, в которых учётные данные отправляются прежде, чем они когда-либо выдавались в захвате, помечаются как used before issue — стоит присмотреться на предмет аномалий пре-аутентификации или фиксации сессии. В список попадают только те учётные данные, которые в захвате и выдаются, и используются.
Та же реконструкция классифицирует эндпоинты аутентификации по паттерну пути, так что запросы login, logout, обновления токена, сброса пароля, регистрации, OAuth authorize/token, MFA и magic-link перечисляются в хронологическом порядке — это карта поверхности аутентификации цели для планирования дальнейших разрешённых тестов. Быстро сопоставить запросы, несущие учётные данные, можно с помощью глобального поиска (/docs/ru/analysis/search/).