JWT alg:none — обход аутентификации без подписи

# JWT: атака на алгоритм подписи ## Сценарий Перед вами Node.js + Express приложение интернет-магазина SecureShop. Аутентификация построена на JWT-токенах: после успешного входа сервер выдаёт клиенту подписанный токен в cookie `token`, и дальнейшие запросы авторизуются именно по нему. Токен виден в cookie клиента и в общих чертах построен по стандарту: заголовок, полезная нагрузка, подпись. Однако в реализации проверки токена допущена ошибка, относящаяся к одной из самых известных категорий проблем JWT-аутентификации. Эндпоинты приложения проверяют токен по-разному: страница профиля работает с токеном корректно, а административный эндпоинт, отдающий конфиденциальную метку (флаг), обрабатывает токен небрежно. Найдите расхождение и используйте, чтобы получить административный доступ, не зная серверного секрета подписи. ## Цели 1. Авторизуйтесь как `demo` / `demo` и изучите cookie с токеном в DevTools. 2. Декодируйте структуру токена (заголовок и полезную нагрузку — это base64url-encoded JSON) и определите, какие поля сервер кладёт в токен и как описывает алгоритм подписи в заголовке. 3. Сравните поведение разных эндпоинтов: какие требуют корректной подписи, а какие — нет. 4. Сформируйте поддельный токен, который пройдёт проверку на привилегированной странице, и извлеките CTF-флаг. ## Данные | Параметр | Значение | |----------|----------| | Обычный пользователь | `demo` / `demo` | | Эндпоинт логина | `POST /login` (выдаёт cookie `token` с подписанным JWT) | | Цель атаки | `GET /admin/flag` (требует `role: admin` в payload) | | Корректно проверяющий эндпоинт | `GET /profile` (для сравнения поведения) | | Серверный секрет | Атакующему неизвестен и не нужен | ## Теория JWT состоит из трёх частей в base64url: `header.payload.signature`. Заголовок содержит поле `alg` — алгоритм подписи (`HS256`, `RS256` и т.п.). Спецификация JWT исторически предусматривает значение, обозначающее «токен без подписи». В современных JWT-библиотеках поддержка такого режима либо удалена, либо требует явного opt-in от разработчика. Параллельно у уязвимости есть более частая форма: разработчик вызывает функцию **декодирования** JWT и доверяет полученным claims, забывая, что декодирование не проверяет подпись. Семантически операции «декодировать» и «верифицировать» отличаются на один глагол, но это разница между парсером и верификатором. Эту ошибку часто допускают, когда payload нужен для логирования или UI, а потом тот же приём по инерции переносят на авторизационные проверки. Если приложение использует функцию декодирования для проверки доступа — клиент сам определяет, как сервер интерпретирует токен.