Pull to refresh

Comments 25

Заголовок [...] Чаще всего состоит из двух полей: [...] Алгоритм хэширования

alg — это не алгоритм хэширования. Это вообще криптографический алгоритм (RFC 7515). И они будут отличаться в зависимости от того, JWS у ваc, или JWE.


Официальный сайт предлагает два алгоритма хэширования:

Нет никакого "официального сайта". Есть RFC 7519 (с обновлениями).


Но на самом деле любой алгоритм с приватным ключом может быть использован.

Что такое "алгоритм хэширования с приватным ключом"? Правильно, нет такой вещи. Смотри первый пункт в этом комментарии. И нет, в alg может быть не любой алгоритм: JWS, JWE.


Как правило, JWT может быть сгенерирован с помощью двух механизмов шифрования

… и дальше хорошо видно, что вы путаете шифрование с подписанием.


если конфигурация JWT не реализована правильно

Что такое "конфигурация JWT"? На стороне издателя или на стороне проверяющего?


(но вообще, конечно, приведенные атаки — это наглядная иллюстрация того, почему не надо делать свою собственную безопасность на основе JWT, а надо брать готовые решения, желательно стандартизованные)

Приблизительно при этом: "Веб-токены JSON – это еще одна форма пользовательского ввода". Грубо говоря, если кто-то от большого ума взял значение из пришедшего токена, и запихнул его в SQL-запрос (например, чтобы найти издателя по пришедшему идентификатору) без соответствующей обработки, то можно получить SQL-инъекцию.


Это, понятное дело, атака не на токен, а с помощью токена. И она предполагает, что выполнилось множество предусловий.

Так я именно об этом. Это имеет к токену точно такое же отношение, как к… ну в общем, притянуто за уши.

Ну и да, если взглянуть на оригинал, то большая часть проблем — они оттуда.
Это имеет к токену точно такое же отношение, как к… ну в общем, притянуто за уши.

Полностью согласен.


Ну и да, если взглянуть на оригинал, то большая часть проблем — они оттуда.

А какая разница, откуда? Все равно в итоге тут написана чушь.

Для нас — никакой. А вот автор, раз не поставил значок «перевод» — отвечает за ошибки сам. По-идее.

Даже если поставил — всё равно отвечает, ибо нефиг переводить чушь.

Ну в общем да. Но все-таки, в случае перевода можно приписать что-то типа: «Во, смотрите какую неоднозначную чушь пишут на медиуме» :)
ля, самая простая ошибка, которую допускают при использовании JWT (лично сталкивался) — это использование данных, хранящихся в токене на бэкэндах без валидации. Ну типа есть у нас токен с юзеридом, ролью, аваторкой, логином и прочими данными. Так вот, роль пользователя при проверке доступа на бэкэнде бралась из токена, а не из базы, что могло привести к ситуациям, когда юзера разжаловали из админов, а токен еще не истек, соответственно для бэкэнда этот юзер был до сих пор в админах. Либо еще вариант — когда юзер уален из базы, а токен опять же еще не истек, и этот юзер может получать данные, как авторизованный. Ситуация хоть и довольно специфическая, но в ряде случаев может привести ко всяким казусам, а в случае кибербулингаатаки и вовсе сыграть на руку всяким злоумышленникам

Но если брать данные из базы — то зачем вообще токен?

для фронтэнда, как хранилище пользовательской инфы без дополнительных сущностей. Если фронт отобразит неактуальную инфу, это не страшно, а вот если эта неактуальная инфа используется для выполнения каких-либо операций, это становится проблемой. И что страшного в лишнем запросе к базе или кэшу? Оптимизация? Если оптимизация ухудшает безопасность — нафиг такую оптимизацию, ящитаю

А зачем для фронтэнда полноценный JWT? Он же бэку доверяет, а значит может запросить информацию о пользователе через API в произвольной форме.


И что страшного в лишнем запросе к базе или кэшу?

Да ничего страшного, просто если мы такой запрос делаем — нам JWT нахрен не нужен.

Как раз чтобы лишний запрос к апи не делать. Обработка запроса все же более затратная операция, чем получение данных из базы/кэша. Использовать JWT без валидации можно только в том случае, если операция не требует актуальной инфы о пользователе, но как правило, для выполнения подобных операций и авторизация не всегда нужна.

Но ведь фронт как-то JWT получает? В этот момент можно и любую информацию о пользователе получить, только её не обязательно в токен включать.

Ну да, оно так и работает, но есть ньюанс — пока токен не истек, его можно хранить и использовать. Так как для выполнения критических операций все равно требуется валидация пользовательской инфы, время жизни токена можно увеличить без ущерба для безопасности (если не рассматривать ситуации, когда у юзера воруют этот самый токен, т.к. угнав даже истекший токен его можно обновить, OAuth в этом плане побезопаснее, т.к. токены там одноразовые, в том числе и refresh-токен), что позволяет не запрашивать данные при перезагрузке страницы.
Еще один плюс — если мы берем пользовательскую инфу из базы, можно при выполнении операции сравнить ее с данными, хранящимися в токене, и при несоответствии одного из полей сразу выдавать новый токен с обновленной инфой. Короче удобная штука получается
А за что минус-то? Если я где-то неправ, поправьте
Ну я так думаю ошибка в том, что инвалидация токена это совсем другая проблема и решается она по другому. Так что в брать роль с токена это нормально. А ваше решение возвращает нас назад к сессиям…

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


С развитием REST количество запросов к бэку для рендера одной страницы увеличилось в несколько раз, при этом сессии не всегда можно использовать (микросервисы, серверлесс и т.д.). Проверка данных пользователя это зачастую тяжелая операция и делать ее на каждый вызов API — большие накладные расходы.


С JWT мы можем один раз сгенерировать токен с необходимыми данными и затем на бэке просто проверять, что токен нас не обманывает (проверка подписи с каким-нибудь кэшированным или хардкод ключем).


Действительно — у JWT токенов есть потенциальные проблемы с тем, что данные токена могут не отражать реальной картины, однако это просто особенность технологии, которая имеет свои решения.

Токены можно давать допустим на час.

При отсутствии валидации даже 15 минут — это дохрена, а час и подавно. Опять же зависит от области применения — если сервис, использующий JWT не выполняет критических для системы операций, либо не работает с конфиденциальными данными, то такой подход и может быть оправдан. Если работает — такое использование JWT создает дыру в безопасности сервиса
Только вот сервис, который получает JWT — это совсем не тот сервис, который JWT выдаёт. Доступа к базе пользователей сервис-получатель не имеет и для валидации должен сделать дополнительный запрос к API сервиса управления пользователями.
И это ничем не лучше, чем дополнительный запрос к API из front-end.
ну так это уже особенности архитектуры, в описаном мной случае доступ к базе есть
Да уж… Статья не про атаки на JWT, а про возможные атаки с помощью JWT на системы, криво настроенные/написанные.
Лучше было бы написать о том, про что надо не забыть, используя JWT… И про валидацию, и про срок жизни, и про надёжное хранению ключей.
Only those users with full accounts are able to leave comments. Log in, please.