JWT: Key Confusion (RS256 to HS256)

# JWT-подмена алгоритма: публичный ключ как HMAC-секрет ## Сценарий Магазин электроники **TechnoPort** аутентифицирует пользователей JWT-токенами с асимметричной подписью: сервер хранит приватный RSA-ключ, подписывает токены алгоритмом RS256 и публикует сопоставленный публичный ключ служебными API — стандартная практика, позволяющая микросервисам проверять токены локально. Пароль администратора никому не известен, а в админ-панели лежит конфиденциальная метка. Вас пригласили на аудит с вопросом: можно ли, имея лишь обычную учётную запись и доступ к публичному ключу, попасть в админ-панель? ## Цель 1. Войдите как обычный пользователь и изучите выданный токен: декодируйте заголовок и полезную нагрузку, определите алгоритм подписи и claims. 2. Найдите служебный эндпоинт, на котором сервер публикует публичный ключ. 3. Сформируйте токен с административными правами, не владея приватным ключом, — воспользовавшись тем, как верификатор выбирает алгоритм проверки и какой материал использует в ветке симметричной проверки. 4. Подмените токен, откройте админ-панель и извлеките флаг. ## Теория **JWT Algorithm Confusion (key confusion)** — атака на верификацию, основанная на смешении классов алгоритмов. Асимметричная схема (RSA) подписывает приватным ключом и проверяет публичным; симметричная (HMAC) использует один секрет на обе стороны. Если верификатор читает поле `alg` из заголовка токена — а заголовок контролирует атакующий, — тот сам выбирает ветку проверки. Указав симметричный алгоритм, атакующий заставляет сервер проверять HMAC-подпись; а если в этой ветке секретом служит материал публичного ключа, атакующий забирает тот же материал с публичного эндпоинта и подписывает любой токен сам. **Уязвимый паттерн:** ```php $alg = $header['alg'] ?? 'RS256'; // алгоритм chosen из заголовка токена if ($alg === 'RS256') { /* проверка публичным ключом */ } else { /* проверка HMAC с секретом из того же ключа */ } ``` В этой лабе в симметричной ветке секретом становятся байты бинарного представления публичного ключа — их атакующий получает из опубликованного PEM, сняв текстовые обёртки и декодировав тело. Второй дефект усиливает первый: роль пользователя берётся из claims токена, а не из БД, поэтому любая успешная подмена подписи даёт ровно те права, что атакующий сам себе выписал. ## Точка входа атаки `POST /login` — вход (выдаёт cookie `token` с JWT); `GET /api/public-key` и `GET /api/jwks` — публикация ключа; `GET /admin` — привилегированная страница с флагом. * **Обычный пользователь:** `demo` / `demo` * **Цель:** токен с административной ролью и флаг из админ-панели