Комментарии 25
Заголовок [...] Чаще всего состоит из двух полей: [...] Алгоритм хэширования
alg — это не алгоритм хэширования. Это вообще криптографический алгоритм (RFC 7515). И они будут отличаться в зависимости от того, JWS у ваc, или JWE.
Официальный сайт предлагает два алгоритма хэширования:
Нет никакого "официального сайта". Есть RFC 7519 (с обновлениями).
Но на самом деле любой алгоритм с приватным ключом может быть использован.
Что такое "алгоритм хэширования с приватным ключом"? Правильно, нет такой вещи. Смотри первый пункт в этом комментарии. И нет, в alg может быть не любой алгоритм: JWS, JWE.
Как правило, JWT может быть сгенерирован с помощью двух механизмов шифрования
… и дальше хорошо видно, что вы путаете шифрование с подписанием.
если конфигурация JWT не реализована правильно
Что такое "конфигурация JWT"? На стороне издателя или на стороне проверяющего?
(но вообще, конечно, приведенные атаки — это наглядная иллюстрация того, почему не надо делать свою собственную безопасность на основе JWT, а надо брать готовые решения, желательно стандартизованные)
А вы можете объяснить, каким боком тут вообще SQL-инъекция?
P.S. Мне кажется, что это вообще-то перевод: medium.com/bugbountywriteup/attacking-json-web-tokens-jwts-d1d51a1e17cb
Приблизительно при этом: "Веб-токены JSON – это еще одна форма пользовательского ввода". Грубо говоря, если кто-то от большого ума взял значение из пришедшего токена, и запихнул его в SQL-запрос (например, чтобы найти издателя по пришедшему идентификатору) без соответствующей обработки, то можно получить SQL-инъекцию.
Это, понятное дело, атака не на токен, а с помощью токена. И она предполагает, что выполнилось множество предусловий.
Ну и да, если взглянуть на оригинал, то большая часть проблем — они оттуда.
Это имеет к токену точно такое же отношение, как к… ну в общем, притянуто за уши.
Полностью согласен.
Ну и да, если взглянуть на оригинал, то большая часть проблем — они оттуда.
А какая разница, откуда? Все равно в итоге тут написана чушь.
Мне кажется, что это вообще-то перевод: medium.com/bugbountywriteup/attacking-json-web-tokens-jwts-d1d51a1e17cb
О, ваше гугль-фу лучше моего. Я смог найти только вот это: https://www.slideshare.net/OWASP_Poland/opd-2019-attacking-jwt-tokens
Нехорошо, да.
Но если брать данные из базы — то зачем вообще токен?
А зачем для фронтэнда полноценный JWT? Он же бэку доверяет, а значит может запросить информацию о пользователе через API в произвольной форме.
И что страшного в лишнем запросе к базе или кэшу?
Да ничего страшного, просто если мы такой запрос делаем — нам JWT нахрен не нужен.
Но ведь фронт как-то JWT получает? В этот момент можно и любую информацию о пользователе получить, только её не обязательно в токен включать.
Еще один плюс — если мы берем пользовательскую инфу из базы, можно при выполнении операции сравнить ее с данными, хранящимися в токене, и при несоответствии одного из полей сразу выдавать новый токен с обновленной инфой. Короче удобная штука получается
JWT как технология как раз и был придуман, чтобы избежать лишних запросов к сторонним данным на бэке на каждый чих.
С развитием REST количество запросов к бэку для рендера одной страницы увеличилось в несколько раз, при этом сессии не всегда можно использовать (микросервисы, серверлесс и т.д.). Проверка данных пользователя это зачастую тяжелая операция и делать ее на каждый вызов API — большие накладные расходы.
С JWT мы можем один раз сгенерировать токен с необходимыми данными и затем на бэке просто проверять, что токен нас не обманывает (проверка подписи с каким-нибудь кэшированным или хардкод ключем).
Действительно — у JWT токенов есть потенциальные проблемы с тем, что данные токена могут не отражать реальной картины, однако это просто особенность технологии, которая имеет свои решения.
Токены можно давать допустим на час.
И это ничем не лучше, чем дополнительный запрос к API из front-end.
Лучше было бы написать о том, про что надо не забыть, используя JWT… И про валидацию, и про срок жизни, и про надёжное хранению ключей.
Атаки на JSON Web Tokens