Безопасность
JWT pitfalls: сломай и закали auth-флоу
Читать про атаки на JWT — не то же самое, что провести одну. Построй небольшой auth-флоу, подделай против него токены — alg:none, путаница RS256→HS256, отсутствующая проверка aud, атакующий kid — затем примени защиты юнита и докажи провалившимся эксплойтом, что каждая дыра закрыта.
Преврати ментальную модель юнита в воспроизводимый security-цикл: построй верификатор, атакуй его как пентестер, закали пиннингом алгоритма и валидацией claim и подтверди каждый фикс эксплойтом, который теперь проваливается.
Построй защищённый JWT API с login, аутентифицированным маршрутом /admin и refresh, затем прогони набор атак (alg:none, путаница алгоритмов, отсутствующий aud, атакующий kid) — сначала доказав, что каждый эксплойт срабатывает против наивной версии, потом — что он проваливается после закалки.
- Таблица до/после для четырёх эксплойтов: каждый достигает /admin (или refresh) против наивного верификатора и отвергается с ясной ошибкой против закалённого — показано реальным выводом запрос/ответ, а не описано.
- Закалённый верификатор отвергает токен с неверным aud, даже когда его signature валидна, и отвергает токен с атакующим kid, ни разу не сходив на названный заголовком URL.
- Повтор отротированного refresh-токена запускает отзыв семейства: следующий refresh легитимной сессии тоже проваливается, доказывая срабатывание детекта повтора (продемонстрировано против работающего сервиса).
- Абзац-разбор, связывающий каждую защиту (пиннинг алгоритма, привязка ключа, проверки claim, allowlist kid, ротация, хранение) с конкретным эксплойтом, который она закрывает, и руководством RFC 8725 за ней.
- Добавь список отзыва (или короткоживущий deny-кэш по jti), чтобы подтверждённо скомпрометированный access-токен можно было убить до exp, и измерь накладные на запрос.
- Добавь демо брутфорса: настрой HS256-путь со слабым выбранным человеком секретом, взломай его офлайн из захваченного токена, затем покажи, что 256-битный секрет из CSPRNG делает ту же атаку неосуществимой.
- Подключи защиту CSRF для refresh-токена в cookie (SameSite плюс CSRF-токен на эндпоинте refresh) и докажи, что межсайтовый запрос refresh отвергается.
- Прогоняй набор атак в CI как security-регрессионный гейт: сборка валится, если любой поддельный токен когда-либо достигнет защищённого маршрута.
Это цикл, который ты будешь запускать на каждом реальном auth-ревью: построй флоу, атакуй его как противник, затем закали, никогда не доверяя токену описывать собственную верификацию — пинь алгоритм, привязывай и allowlist-и ключи, валидируй exp/nbf/iss/aud, резолви kid на сервере и сдерживай утечки короткими TTL, ротацией refresh и XSS-осознанным хранением. Проведя каждый эксплойт раз и увидев его провал после фикса, ты превращаешь RFC 8725 из чек-листа в инстинкт.