ТЛ;ДР Редакторы ИИ регулярно пишут промежуточное программное обеспечение для аутентификации, которое вызывает jwt.decode() там, где требуется jwt.verify(), поэтому подпись токена никогда не проверяется. Затем любой может отредактировать полезную нагрузку, установить «роль»: «admin» и войти. Поддельный токен никогда не...
ТЛ;ДР
Редакторы ИИ регулярно пишут промежуточное программное обеспечение для аутентификации, которое вызывает jwt.decode() там, где требуется jwt.verify(), поэтому подпись токена никогда не проверяется.
Затем любой может отредактировать полезную нагрузку, установить «роль»: «admin» и войти. Поддельный токен никогда не нужно подписывать.
Исправление: проверьте каждый токен с помощью закрепленного списка алгоритмов и используйте jose там, где jsonwebtoken не будет работать.
На прошлой неделе я попросил Cursor добавить защиту маршрутов в небольшое приложение Next.js. Первая версия импортировала jsonwebtoken в middleware.ts, и сборка не удалась, поскольку среда выполнения Edge не имеет криптографического модуля Node.
Поэтому я сказал Cursor исправить ошибку сборки. Так оно и было. Он заменил jwt.verify() на jwt.decode(), сборка стала зеленой, защищенные страницы по-прежнему перенаправляли вышедших из системы пользователей, и все ручные проверки были пройдены.
Приложение теперь принимало любые токены, которые мог ввести каждый.
Уязвимый код
jwt.decode() считывает полезную нагрузку токена, не проверяя его подпись, поэтому любое промежуточное программное обеспечение, которое принимает на его основе решение об аутентификации, доверяет данным, записанным клиентом. Это CWE-347, Неправильная проверка криптографической подписи.
Вот промежуточный курсор Cursor, созданный после «исправления» сборки:
// middleware.ts (CWE-347: подпись не проверялась)
импортировать {NextR