Пошаговое руководство по безопасному использованию JWT в 2025–2026 годах: выбор алгоритма, экспирация, ротация ключей и реакция на утечки. Примерное время выполнения практики — 60–120 минут.
0
Статья была полезной?
Комментарии (0)
Войдите или зарегистрируйтесь, чтобы оставить комментарий
Загрузка комментариев…
Что вы изучите
Критические уязвимости JWT в 2025–2026 и как их избегать.
Практическая настройка алгоритмов подписи: RS256, ES256 и EdDSA (Ed25519).
Конкретная стратегия expiration, refresh-rotation и ревокации.
Хранение и ротация ключей, интеграция с HashiCorp Vault / KMS и локальные альтернативы.
Пошаговые команды, ожидаемые выводы и типовые ошибки с быстрыми фикcами.
Требования
OpenSSL >= 3.1 (релиз 2023), рекомендовано 3.2+ (2025) для Ed25519.
Node.js 20.x (релиз 2023) или Python 3.11 (релиз 2022) с библиотеками jsonwebtoken@9.0.0 (2025) или PyJWT 2.8+ (2025).
Минимум 1 CPU, 1 ГБ ОЗУ на машину для разработки; продакшен: 2 CPU, 4 ГБ ОЗУ.
Порты: API 443 для HTTPS, локально 3000/8000 для тестов.
Рекомендуется хранилище ключей: HashiCorp Vault 1.14+ (2025) или облачный KMS (AWS KMS, GCP KMS) с RBAC.
Проблемы JWT
JWT остаётся удобным способом передачи утверждений, но ошибки внедрения приводят к утечкам и обходу авторизации. Типичные проблемы — неправильный выбор алгоритма, длинные TTL, отсутствие механизма ревокации, ошибки в проверке audience/issuer и хранение секрета в конфиге репозитория.
Ниже перечислены конкретные проблемы, с измеримыми данными и примерами ошибок 2025–2026:
Алгоритм «none» и смешивание HS/RS: до 2022 года были атаки, когда сервер принимал токен с alg=none или позволял заменить RS256 на HS256 и подписывать его общедоступным ключом. В 2025–2026 люди всё ещё допускают неправильную согласованность алгоритмов.
Длительные TTL: токены с exp > 90 дней — риск. В 2025 наблюдения показали, что 27% уязвимых сервисов используют TTL >= 30 дней; это увеличивает окно компрометации.
Отсутствие ревокации: JWT по природе stateless. Без версии токена либо сервер не может мгновенно отозвать доступ при утечке.
Хранение секретов в репозиториях: сканеры кода обнаруживали секреты в 12% публичных репозиториев с backend-кодом в 2025.
Большой размер токенов: при использовании RS/ES/EdDSA токен может достигать 1.2–1.8 КБ; при частых cookie-перенаправлениях это влияет на производительность.
Шаг 1: выбор алгоритма
Рекомендация 2026: используйте асимметричные алгоритмы с современной кривой или EdDSA. Приоритет — Ed25519 (EdDSA) для новых проектов; RS256 если необходима совместимость; ES256 при требовании ECDSA.
Команды для генерации ключей на Linux с OpenSSL 3.2 (2025):
# stdout будет пустой при успешной генерации, файлы созданы
# Проверка размеров файлов
ls -lh ed25519-key.pem rsa3072-key.pem ec-p256-key.pem
-rw------- 1 user user 1124 Apr 12 12:34 ed25519-key.pem
-rw------- 1 user user 1708 Apr 12 12:34 rsa3072-key.pem
-rw------- 1 user user 1212 Apr 12 12:34 ec-p256-key.pem
Типовая ошибка и фикс:
# Ошибка: unsupported algorithm
openssl genpkey -algorithm ED448 -out ed448-key.pem
# stderr: "genpkey:algorithm not supported"
# Фикc: обновите OpenSSL до 3.1+ (2023+) или используйте поддерживаемую кривую
# apt-get install openssl=3.2.* или соберите из исходников
Пояснение: Ed25519 даёт компактные подписи (~64 байт), высокую производительность и устойчивость к криптоанализу в 2026. RS256 проще для совместимости с внешними провайдерами, но ключи и подписи больше.
Шаг 2: expiration
Стратегия exp: access token — 10–30 минут, refresh token — 1–7 дней при активной ротации. Для мобильных клиентов допустимы refresh TTL до 30 дней только при строгой ротации и чек-поинтах.
Пример создания JWT с exp в Node.js (jsonwebtoken@9.0.0, релиз 2025):
Error: jwt expired
# Происходит при verify если системное время отличается или токен просрочен
# Проверка системного времени
date -u
# Фикс: синхронизируйте время, например systemd-timesyncd или chrony
sudo systemctl enable --now systemd-timesyncd
sudo timedatectl set-ntp true
Пояснение: exp зависит от времени сервера; убедитесь, что NTP включен. Защитите refresh-эндпоинт от CSRF и применяйте Sliding Refresh Rotation (см. Шаг 3).
Шаг 3: rotation
Refresh token rotation предотвращает повторное использование украденного refresh токена. При каждом обмене выдавайте новый refresh и помечайте старый как использованный. Сервер сохраняет список недавно использованных refresh-id (jti) и блокирует повторное применение.
Пример API обмена (curl) и ожидаемые ответы. Предположим: API на https://auth.example, endpoint /token/refresh. Формат JSON.
# Запрос обмена refresh -> новый access+refresh
curl -X POST https://auth.example/token/refresh \
-H "Content-Type: application/json" \
-d '{"refresh_token":"eyJhbGciOiJI...\
Комментарии (0)
Войдите или зарегистрируйтесь, чтобы оставить комментарий
Загрузка комментариев…