Перейти к содержимому

Поиск по платформе

JWT: Key Confusion (RS256 to HS256)

Сервер подписывает JWT через RS256, но не проверяет алгоритм при валидации. Атакующий скачивает публичный ключ и подписывает HS256-токен этим ключом как HMAC-секретом.

Автор: Hack & Fix
Освоишь: bcrypt/argon2constant-time compareMFA
Сложно+90 XP ~65 мин python
CWE-287 · A07:2021 Pro
Обложка: JWT: Key Confusion (RS256 to HS256) Обложка: JWT: Key Confusion (RS256 to HS256)
Задача
# JWT: подмена алгоритма подписи (key confusion) ## Сценарий Вы — аудитор **NetCart**, интернет-магазина, готовящегося подключить партнёрскую систему единого входа. Прежде чем доверить магазин внешним токенам, вас направили проверить собственный механизм сессий: вход выдаёт JWT-токен с асимметричной подписью, приватный ключ есть только у сервера, а публичный опубликован для всех проверяющих. Партнёр уже спросил, «точно ли сервер не примет токен, подписанный чем-то ещё», — вам предстоит ответить на этот вопрос практически. ## Цель 1. Войдите под обычной учётной записью и изучите JWT-токен в cookie: структуру, алгоритм подписи, набор полей. 2. Найдите опубликованный способ получения ключа проверки и разберитесь, как сервер использует этот ключ при разных алгоритмах из заголовка токена. 3. Сформируйте токен с административной ролью, который сервер примет, не располагая приватным ключом, откройте админ-панель и заберите CTF-флаг. ## Теория В асимметричной схеме подписать токен может только владелец приватного ключа, а проверить — любой, у кого есть публичный. Схема ломается, если верификатор соглашается проверять симметричной подписью: секретом HMAC выступает сам материал проверки, а он по определению публичный. Это и называется key confusion — «путаница ключей». **Уязвимый паттерн:** ```python alg = header.get('alg', 'RS256') if alg == 'RS256': decoded = pyjwt.decode(token, _public_key, algorithms=['RS256']) ``` Алгоритм верификации читается из заголовка токена — а заголовок полностью контролируется клиентом. Если вместо асимметричного названия указано симметричное, сервер проверяет подпись теми же байтами публичного ключа, но уже как общим секретом. Роль пользователя при этом доверенно берётся из полей токена, поэтому подделанная полезная нагрузка сразу даёт права. ## Точка входа атаки Токен хранится в cookie `token` после входа. Ключ проверки публикуется на `GET /api/public-key`; дополнительно приложение отдаёт его в структурированном виде на `GET /api/jwks`. Проверка подделки — вход в админ-панель `GET /admin`. * **Обычный пользователь:** `demo` / `demo` * **Цель:** сессия с ролью администратора

Похожие лабораторные (4)

другие лабы по этой уязвимости
Обложка лабы: Timing-атака на форму входа Обложка лабы: Timing-атака на форму входа
Auth

Timing-атака на форму входа

Обработчик входа раскрывает существование пользователей через разницу во времени ответа — bcrypt вызывается только для существующих аккаунтов.

+60 XP
Python Pro
Exploit Fix
Обложка лабы: JWT: None Algorithm Attack Обложка лабы: JWT: None Algorithm Attack
Auth

JWT: None Algorithm Attack

Сервер принимает JWT с alg:none и доверяет роли из claims — подделайте токен для получения прав администратора.

+60 XP
Python Pro
Exploit Fix
Обложка лабы: Брутфорс Формы Входа (Нет Rate Limiting) Обложка лабы: Брутфорс Формы Входа (Нет Rate Limiting)
Auth

Брутфорс Формы Входа (Нет Rate Limiting)

Форма входа не ограничивает количество попыток, позволяя подобрать пароль администратора перебором по словарю.

+30 XP
Python Pro
Exploit Fix
Обложка лабы: Слабая Парольная Политика Обложка лабы: Слабая Парольная Политика
Auth

Слабая Парольная Политика

Регистрация принимает любой пароль без проверки сложности. Пароль администратора — 'admin'.

+30 XP
Python Pro
Exploit Fix