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

# JWT: обход аутентификации через алгоритм без подписи ## Сценарий Магазин электроники **ChipCart** перевёл вход с сессий на токены: после логина сервер выдаёт подписанный JWT в cookie, и каждый запрос авторизуется по нему. Разработчик сделал всё «по стандарту» — токен из трёх частей, подпись секретом сервера. Однако внешний ревьюэр, наблюдая за поведением приложения, заподозрил, что проверка токена доверяет ему больше, чем следует. Продавец магазина просит проверить: можно ли попасть в админ-панель, не зная ни пароля администратора, ни секрета подписи. ## Цель 1. Войдите покупателем и найдите токен в cookie; декодируйте заголовок и полезную нагрузку. 2. Определите, как сервер выбирает способ проверки подписи и все ли допустимые режимы проверки одинаково строги. 3. Сформируйте токен, который сервер принимает как валидный и который даёт права администратора. 4. Откройте админ-панель и получите флаг. ## Теория JWT состоит из трёх частей: заголовок, полезная нагрузка, подпись. В заголовке клиент объявляет алгоритм подписи — и если сервер следует этому объявлению, контроль над способом проверки переходит к отправителю токена. Стандарт исторически допускает режим «без подписи», рассчитанный на уже доверенный контент; для аутентификации он непригоден. **Уязвимый паттерн:** ```js claims = jwt.decode(token); // подпись не проверяется claims = jwt.verify(token, JWT_SECRET, { algorithms: ['HS256', 'none'] }); // «без подписи» — в списке разрешённых ``` Когда сервер принимает неподписанный токен, содержимое полезной нагрузки определяет клиент: достаточно записать туда свой идентификатор и роль администратора. Роль при этом читается из токена, а не из базы, — подделка сразу даёт полные права. ## Точка входа атаки `POST /login` — форма входа с полями `username` и `password`; после входа токен лежит в cookie `token`. Подмена токена выполняется в этом же cookie; цель — `GET /admin`. * **Пользователь:** `demo` / `demo`