Я тебе не верю! JWT, JWS, JWE и Zero Trust

С ростом сложности распределённых систем и микросервисов обеспечение безопасности обмена данными становится не просто задачей, а ключевым условием существования современных приложений. JWT, являясь уже стандартом передачи идентификационных и авторизационных данных, требует глубокого понимания тонкостей своей реализации в первую очередь безопасниками. Особенно это касается применения JWS, JWE и интеграции принципов архитектуры/философии Zero Trust.

JWT – JSON Web Token
JWS – JSON Web Signature
JWE – JSON Web Encryption

✏️ Подпись и целостность токенов

JWS предназначен для защиты целостности и подтверждения подлинности JWT. Важно отметить, что подпись JWS не шифрует содержимое токена, а лишь предотвращает его модификацию.

Основные алгоритмы, применяемые в JWS:
🔵 RS256 (RSA Signature с SHA-256)
🔵 ES256 (ECDSA Signature с SHA-256)

На что стоит обратить внимание при проверке JWS:
🔵 Алгоритм подписи;
🔵 Валидность публичного ключа;
🔵 Корректная валидация всех полей claims (aud, iss, exp и др.).

Частая ошибка, которую допускают разработчики - отсутствие проверки используемого алгоритма, что может привести к атакам типа "none algorithm" или подмене алгоритма подписи.

Пример:

token, err := jwt.Parse(tokenString, func(token *jwt.Token) (interface{}, error) {
 return publicKey, nil
})

🌐 Шифрование чувствительных данных

В отличие от JWS, JWE предназначен для защиты конфиденциальности данных внутри JWT. Использование JWE позволяет гарантировать, что только владелец приватного ключа сможет прочитать данные токена.

При реализации JWE важно обеспечить:
🟢 Надежное управление ключами;
🟢 Правильный выбор алгоритмов (например, RSA-OAEP и AES-GCM);
🟢 Отсутствие утечек ключей и материалов шифрования в логах или памяти.

👮‍♀️ Zero Trust и JWT

Zero Trust требует, чтобы каждый запрос проверялся независимо, не доверяя никаким промежуточным слоям. JWT идеально вписывается в эту модель при некоторых условиях:
🟢 Независимой проверки JWT каждым микросервисом;
🟢 Минимального lifetime токенов;
🟢 Глубокой валидации всех claims и строгой политики доступа.

А в ваших микросервисах всё так ?)

«Безопасность — не продукт, а процесс»

Наверное, одно из моих любимых выражений, которую не понимают многие люди из ИБ

❔ Уязвимый фрагмент кода для анализа

Как я и говорил, что немного меняю подход к обучающим постам, теперь в каждом из них будет идти код с ошибкой (Я могу и сам ошибиться в ошибке, не серчайте 🤪).

Так вот, что тут не так и где беда?

func ValidateToken(tokenString string, publicKey *rsa.PublicKey) (*jwt.Token, error) {
 token, err := jwt.Parse(tokenString, func(token *jwt.Token) (interface{}, error) {
  if _, ok := token.Method.(*jwt.SigningMethodRSA); !ok {
   return nil, fmt.Errorf("Неожиданный алгоритм подписи: %v", token.Header["alg"])
  }
  return publicKey, nil
 })
 if err != nil {
  return nil, err
 }
 return token, nil
}

Телеграмм не позволяет делить открытие скрытого текста, поэтому ответ будет отправлен спустя 1 день.

Также мне нужна обратная связь по ЯП. Я умею в Go, Python, немного в Java и JS. Вы не будте против, если при коде на других языках, Вас будет проверять ИИ?

Подсказка:
Обрати внимание на то, что код проверяет только тип алгоритма, но не конкретный алгоритм и не проверяет claims. Почему это может быть критично?

❕ Заключение и краткие рекомендации

Для повышения безопасности JWT необходимо:
🟢 Всегда явно проверять указанный алгоритм подписи (например, RS256);
🟢 Обязательно проверять и валидировать все критически важные claims (iss, aud, exp);
🟢 Использовать JWE для защиты чувствительных данных внутри JWT;
🟢 Следовать Zero Trust модели с обязательной независимой валидацией JWT каждым сервисом.

В заключение мне хочется сказать, что тема JWT стала основным, что я спрашиваю у людей на собеседовании, потому что это БАЗА, которую нужно знать.

#appsec