Ловушки верификации JWT: алгоритмы, claims и ключи

Заголовок — это недоверенный ввод

JWT состоит из трёх частей: заголовок, payload, подпись. Инстинкт — обращаться со всем токеном как с запечатанным конвертом, где надо лишь проверить печать. Но заголовок — включая alg (каким алгоритмом подписано) и kid (каким ключом) — приходит до того, как ты что-либо проверил. Это контролируемый атакующим ввод. Верификатор, который читает alg из заголовка и затем проверяет «так, как говорит токен», отдал атакующему руль: он выбирает алгоритм, ты подчиняешься. Два классических обхода живут ровно в этом разрыве.

alg: none. Спецификация JWS определяет небезопасный алгоритм, буквально названный none, для случаев, где целостность гарантирована другими средствами. Токен с alg: none несёт пустую подпись. Наивный верификатор, который уважает выбор заголовка, увидит «алгоритм: none, подпись: (пусто)» и заключит, что токен валидно подписан — потому что для none пустая подпись и есть валидная. Атакующий переписывает payload на role: admin, ставит alg: none, не шлёт подпись и становится кем угодно.

Путаница ключей HS256/RS256. Это та самая из вступления, и она тоньше. RS256 асимметричен: IdP подписывает приватным ключом, ты верифицируешь парным публичным. HS256 симметричен: один и тот же секрет и подписывает, и верифицирует. Теперь представь, что твоему verify-коду передан публичный ключ RS256, но алгоритм он выбирает из заголовка. Атакующий шлёт alg: HS256. Библиотека, доверяющая заголовку, идёт по HMAC-пути — и использует переданные тобой байты (публичный ключ RS256) как HMAC-секрет. Публичный ключ публичен. У атакующего он есть. Поэтому он вычисляет валидный HS256-MAC над своим поддельным payload, и верификатор это подтверждает.

// УЯЗВИМОСТЬ: верификатор позволяет токену самому выбирать алгоритм.
// Нет allowlist `algorithms`, нет audience, нет issuer.
@Injectable()
export class JwtStrategy extends PassportStrategy(Strategy) {
  constructor() {
    super({
      jwtFromRequest: ExtractJwt.fromAuthHeaderAsBearerToken(),
      secretOrKey: PUBLIC_KEY, // публичный ключ RS256 — но RS256 ничем не закреплён
      // БАГ: без `algorithms` принимается токен с alg:none или HS256
      // БАГ: без `audience`/`issuer` доверяется любой подписанный токен
    });
  }
  validate(payload: any) { return { userId: payload.sub, role: payload.role }; }
}

Фикс для обоих — одно и то же движение: перестань давать токену выбирать. Передай в verify явный allowlist допустимых алгоритмов. Если ожидаешь RS256, скажи algorithms: ['RS256'], и верификатор откажет none и откажет HS256 до того, как вообще посмотрит на подпись — симметричный путь и небезопасный путь для этого верификатора просто не существуют.

// THE FIX: pin the algorithm, the audience, and the issuer.
@Injectable()
export class JwtStrategy extends PassportStrategy(Strategy) {
  constructor(config: ConfigService) {
    super({
      jwtFromRequest: ExtractJwt.fromAuthHeaderAsBearerToken(),
      // for an external IdP, fetch keys from its JWKS endpoint, selected by `kid`:
      secretOrKeyProvider: passportJwtSecret({
        cache: true,
        rateLimit: true,
        jwksUri: config.get('IDP_JWKS_URI'),
      }),
      algorithms: ['RS256'],                  // <- the token can no longer choose
      audience: config.get('API_AUDIENCE'),   // <- this token was minted for US
      issuer: config.get('IDP_ISSUER'),       // <- by OUR trusted IdP
      // exp/nbf are validated by default unless you disable them — leave them on
    });
  }
  validate(payload: JwtPayload) { return { userId: payload.sub, role: payload.role }; }
}

Валидной подписи недостаточно

Допустим, ты запинил алгоритм и подпись честно проверяется. Доверять claims токена всё равно нельзя, потому что подпись доказывает ровно одно: байты не были подменены кем-то без ключа. Она ничего не говорит о том, когда токен валиден и для кого он был выпущен.

exp и nbf — свежесть. exp (истечение) и nbf (не ранее) ограничивают окно валидности токена. Большинство библиотек проверяют их автоматически, если ты их не отключишь (ignoreExpiration: true в passport-jwt — это грабли). Подпись остаётся валидной вечно; только exp делает так, что утёкший или вышедший из системы токен перестаёт работать. Проверяй их.

aud — audience. aud называет сервис, для которого выпущен токен. Это claim, который команды забывают, и он вызывает отказ типа confused-deputy (неавторизованное действие через делегата). Представь внутренний сервис и публичный API, которые ради удобства делят один ключ подписи (или один IdP, выпускающий для обоих). Токен, выпущенный для внутреннего сервиса, — совершенно валидный, корректно подписанный токен. Без проверки aud публичный API его принимает — предъявитель теперь владеет токеном, никогда не предназначавшимся этой поверхности. Проверка audience говорит «я принимаю только токены, чей aud — это я», и межсервисный replay умирает.

iss — issuer. iss пинит, какому IdP ты доверяешь. Если ты его пропустишь и твой набор доверенных ключей пересекается с другим issuer, токен от не той инстанции может проскочить. Проверяй, что iss — это твой IdP.

И не доверяй прикладным claims вроде roles или sub сверх того, что покрывает подпись и что заново перепроверяет твой слой авторизации — подпись гарантирует, что issuer положил эти claims туда, а не что они всё ещё отражают текущее состояние пользователя.

Вместе эти четыре проверки — exp/nbf, aud и iss — закрывают разрыв между «подпись проверилась» и «токену можно доверять». Без любой из них корректно подписанный токен не того времени, не того сервиса или не того issuer проходит насквозь.

Ключи, которые умеют ротироваться

Последняя ловушка — управление ключами. Для асимметричной верификации против внешнего IdP (Auth0, Cognito, Keycloak) не хардкодь публичный ключ. IdP ротируют ключи подписи, и захардкоженный ключ превращает рутинную ротацию в инцидент — или хуже, давит на тебя отключить верификацию, чтобы «починить». Вместо этого бери публичные ключи из JWKS-эндпоинта IdP и выбирай нужный по kid из заголовка токена, с кэшированием и путём обновления, чтобы новые ключи подхватывались. В NestJS это secretOrKeyProvider, подключённый к passportJwtSecret из jwks-rsa, с cache: true и rateLimit: true, чтобы и не долбить эндпоинт, и не закэшировать снятый ключ навсегда.

Для симметричного случая (HS256 с общим секретом) секрет несёт всю модель доверия: любой, у кого он есть, может подделать любой токен. Поэтому он должен быть высокоэнтропийным (не словарное слово, не буквальная строка "secret") и пер-окруженческим, чтобы утёкший staging-секрет не мог подделать production-токены. Слабый или утёкший HS256-секрет — это полная компрометация: нет разделения публичный/приватный, на которое можно опереться.