Безопасность
JWT pitfalls: тест с выбором ответа
Суть Тест с выбором на синтез по всему юниту JWT-pitfalls — alg:none, путаница RS256→HS256, проверка claim, отзыв и компромиссы хранения токенов.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеШесть вопросов поперёк всего юнита. Каждый отражает реальное решение о верификации — не определение для заучивания, а границу доверия, которую надо защитить против атакующего, контролирующего токен.
Цель
Убедись, что связываешь сбои JWT — доверие к алгоритму, привязку ключа, проверки claim, отзыв и хранение — в одно правило: никогда не позволяй токену описывать, как его проверять.
Викторина
Completed
Версия библиотеки принимает токен с заголовком alg:none и пустым сегментом signature, возвращая valid. Почему это катастрофа и какой фикс в одну строку?
Heads-up JWT по умолчанию подписываются, а не шифруются, и шифрование — отдельная задача. Брешь целостности — это принятие пустой signature; шифрование не остановит верификатор, доверяющий alg:none.
Heads-up exp — это просто ещё один контролируемый атакующим claim, как только signature не проверяется. С принятым alg:none атакующий ставит exp каким угодно вместе с role:admin.
Heads-up Угадывать нечего — alg:none означает полное отсутствие подписи. Длина ключа нерелевантна; верификатор должен прямо отвергать алгоритм none.
Викторина
Completed
В атаке путаницы RS256→HS256 каким секретом атакующий подписывает поддельный токен и почему сервер его принимает?
Heads-up Никакого восстановления приватного ключа нет; RSA не взломан. Атака использует публичный ключ как симметричный секрет — он уже опубликован в JWKS-эндпоинте.
Heads-up Ничего не брутфорсится. HMAC-секрет — это публичный ключ, доступный свободно, поэтому атакующий вычисляет валидную HS256-подпись напрямую.
Heads-up Cookie не связаны с подписью JWT. Путаница работает чисто потому, что верификатор позволяет заголовку выбрать HS256 и скармливает HMAC-пути ключ, привязанный к RS256.
Викторина
Completed
Сервис корректно пинит alg:RS256 и проверяет signature, но токен, выпущенный для другого микросервиса в том же домене доверия, принимается как свой. Какой проверки claim не хватает?
Heads-up exp управляет временем жизни, а не предполагаемым получателем. Совершенно свежий токен для другого audience всё равно неверен для этого сервиса; только aud/iss привязывают его к нужному потребителю.
Heads-up Валидность signature лишь доказывает аутентичность выпуска. Без aud любой сервис, делящий ключ, принимает токены, выпущенные для любого другого сервиса — confused-deputy через домен доверия.
Heads-up kid выбирает, какой ключ проверяет signature; здесь signature уже прошла. Дефект — принятие токена, чей audience — совсем другой сервис.
Викторина
Completed
Заголовок токена несёт kid, указывающий на https://attacker.example/jwks.json, и сервер берёт ключ по этому URL для проверки. В чём сбой и фикс?
Heads-up HTTPS аутентифицирует собственный сервер атакующего, а не то, что ключ — твой. Заголовок выбрал локацию, поэтому безопасность транспорта не мешает атакующему отдать ключ, который он контролирует.
Heads-up Кэширование переданного атакующим ключа лишь закрепляет неверный ключ. Дефект — вообще брать ключ из локации, названной заголовком; пинь доверенные ключи на стороне сервера.
Heads-up kid выбирает ключ проверки. Если сервер тянет ключ, на который указывает заголовок, атакующий полностью контролирует верификацию — противоположность косметике.
Викторина
Completed
Пользователь сообщает, что его сессию угнали. С stateless JWT почему нельзя разлогинить его на стороне сервера и что ограничивает ущерб?
Heads-up Stateless JWT никогда не был в твоей базе — в этом весь смысл. Удалять нечего; токен валиден до exp, если не добавить список отзыва.
Heads-up Удаление копии клиента ничего не делает с токеном, который атакующий уже выкрал. Он валиден до exp независимо от состояния cookie клиента.
Heads-up JWT не одноразовые; тот же JWT воспроизводим, пока не пройдёт его exp, — именно поэтому важны короткие TTL и ротация.
Викторина
Completed
SPA должна переживать перезагрузку страницы. Какое разделение хранения отгружает security-минд senior и почему?
Heads-up localStorage читается любым скриптом на странице, так что один XSS-баг выкрадывает оба токена — включая долгоживущий refresh-токен, потерять который хуже всего. Для localStorage нет аналога httpOnly.
Heads-up Снятие httpOnly оставляет cookie читаемой JavaScript, так что ты сохраняешь экспозицию XSS И добавляешь поверхность CSRF от автоматической отправки cookie — худшее из обеих моделей.
Heads-up Память — это хорошо, но у 24-часового access-токена нет быстрого отзыва, и ты убрал ротацию refresh, детектящую повтор. Короткий TTL плюс ротация — в этом весь смысл.
Итог
Сквозная линия юнита — одно правило: никогда не доверяй токену описывать собственную верификацию. alg:none и путаница RS256→HS256 умирают, когда ты пинишь явный allowlist алгоритмов и привязываешь каждый ключ к одному алгоритму; контролируемые атакующим kid/jku умирают, когда ты резолвишь ключи только по закреплённому allowlist. Валидная signature необходима, но недостаточна — проверяй aud и iss, чтобы токен был привязан к ЭТОМУ сервису. А поскольку stateless-токен нельзя «отвыпустить», короткие TTL access, ротация refresh-токена с детектом повтора и XSS-осознанное хранение ограничивают то, что утечёт.