Инструменты разработчика · Декодер JWT
Декодирование против проверки: что доказывает подпись JWT и почему декодеры ее пропускают
· Как это работает
JWT безопасность криптография
Для декодирования не нужен ключ; проверка требует правильного. В этом посте объясняется, что охватывает подпись, чем отличаются HMAC и асимметричная проверка и почему инструмент, предназначенный только для декодирования, честно ничего не доказывает.
Он декодировался нормально, поэтому он должен быть действительным — предположение, которое приводит к принятию поддельных токенов.
Токен может идеально декодироваться после того, как злоумышленник запишет новую полезную нагрузку и прикрепит произвольный текст в качестве третьего сегмента. Анализ Base64url и JSON является общедоступными преобразованиями; ни один из них не проверяет, кто собрал строку. Таким образом, «претензии появились на экране» не являются доказательством того, что эмитент их создал или утвердил.
ToolAcre усиливает эту границу в нескольких местах. Результат всегда содержит `signatureVerified: false`, пользовательский интерфейс повторяет предупреждение о непроверенных заявках рядом с выводом, а тесты подтверждают отсутствие поверхности `valid` или `verify`. Это намеренная честность, а не недостающая функция удобства.
Что охватывает подпись — точные байты закодированного заголовка и полезной нагрузки, соединенные точкой.
Для компактного JWS ввод подписи представляет собой закодированный сегмент защищенного заголовка, литеральную точку и закодированный сегмент полезной нагрузки. Проверка касается именно этих закодированных байтов, а не свеженапечатанных JSON. Изменение порядка свойств или изменение пробелов может привести к созданию разных байтов, даже если человек видит эквивалентные объекты.
Третий сегмент содержит закодированную подпись или MAC байт, созданных на этом входе. ToolAcre сохраняет необработанный сегмент и может сообщать его длину в байтах, но никогда не выполняет криптографическую проверку. Измерение формы данных не позволяет установить, что их создал ожидаемый ключ или что первые два сегмента остались неизменными.
HMAC против асимметричного — общий секрет, который любой, кто может проверить, может также подделать, в отличие от открытого ключа, который можно только проверить.
При использовании HMAC общий секрет поддерживает как создание, так и проверку MAC. Сторона, способная подтвердить этот секрет, также может выпустить другой токен, поэтому распределение секрета определяет границу доверия. Примечания ToolAcre делают это следствие явным для его признанных меток алгоритма HS.
Асимметричные подписи отделяют возможность частной подписи от материалов публичной проверки. Наличие открытого ключа может поддерживать проверку без предоставления полномочий на подпись. Это различие не делает асимметричную метку, объявленную в заголовке, заслуживающей доверия: проверяющий уже должен знать, какой алгоритм и ключ эмитента являются приемлемыми.
Откуда берется ключ — конфигурация общих секретов, конечная точка JWKS для открытых ключей, сопоставленная ребенку
Общие секреты должны исходить из конфигурации защищенной службы, а не из текста токена. Открытые ключи проверки могут поступать из отношений доверенного эмитента и контролируемого набора ключей. `kid` может помочь сделать выбор внутри этого набора, но он не должен превращать произвольное ненадежное содержимое заголовка в файл, базу данных или поиск в сети.
ToolAcre не имеет конфигурации эмитента и не запрашивает ключ, поэтому там невозможно выполнить ответственную проверку. Обычная веб-страница не может сделать вывод о том, какой организации вы доверяете, какую аудиторию вы обслуживаете или какие алгоритмы допускает ваше приложение. Это входные данные политики приложения, а не свойства, которые можно обнаружить путем декодирования.
Почему для декодирования не нужен ключ: base64url — это кодировка, а не шифрование, поэтому информацию может прочитать каждый.
Для декодирования не требуется ключ, поскольку base64url — это обратимое кодирование, а не шифрование. Заголовок и полезная нагрузка предназначены для перемещения вместе с токеном и могут быть восстановлены любым держателем. Это обеспечивает полезный контроль, но также означает, что конфиденциальная информация не должна быть скрыта за визуальным шумом закодированных символов.
Анализ JSON добавляет только структуру. Он может сказать вам, что `roles` — это массив, а `exp` — число, но не то, что какое-либо из значений является подлинным. ToolAcre отображает структурированные значения в виде текста, а зарегистрированные описания — в виде документации, оставляя авторизацию системе, которая может проверять и применять политику.
Рабочий пример — токен с измененным одним символом полезной нагрузки по-прежнему отлично декодируется; только уведомления о проверке
Начните с синтетического токена, полезная нагрузка которого — `{"sub":"demo","role":"reader"}`. Измените один закодированный символ полезной нагрузки, чтобы байты по-прежнему образовывали действительный JSON, возможно, создавая другую роль. Обе версии могут разделять, декодировать и красиво печатать. Путь декодирования не имеет оснований отвергать измененную версию.
Правильно настроенный верификатор повторно вычисляет или проверяет результат шифрования по измененным входным данным подписи и отклоняет несоответствие. Это сравнение демонстрирует точную границу: успех декодера охватывает синтаксис, а успех верификатора может установить целостность относительно доверенного ключа и разрешенного алгоритма до оценки политики утверждений.
Чего это не касается: декодер ToolAcre JWT никогда не проверяет подпись по своей конструкции; ничто из того, что он показывает, не доказывает подлинность токена
ToolAcre никогда не проверяет подпись. Пустой сегмент получает предупреждение, неправильно сформированная кодировка подписи получает другое, а измеряемые байты сообщаются как присутствующие, но не проверенные. Ни одна из этих ветвей не выдает верного вердикта. Реализация не имеет скрытого пути получения ключа или выполнения алгоритма.
Даже успешная криптографическая проверка не будет автоматически разрешать действие. Сервис-потребитель по-прежнему нуждается в проверках эмитента, аудитории, времени и приложения. Эта статья заканчивается перед настройкой библиотеки, поскольку поддержка и настройки по умолчанию различаются; обратитесь к точному верификатору и версии, используемой вашим сервисом.
Вывод: декодируйте для проверки, проверяйте для доверия — используйте декодер ToolAcre JWT для первого и серверную библиотеку с правильным ключом для второго.
Декодирование для проверки и проверки перед доверием. Используйте инструмент браузера для просроченного или синтетического токена, когда вам нужно просмотреть поля заголовков, значения полезной нагрузки, преобразования времени и структурные предупреждения. Никогда не позволяйте этому читаемому выводу напрямую влиять на решение о доступе.
Перенесите последующую работу доверенному проверяющему, который самостоятельно предоставит ключевой материал, закрепленные алгоритмы и политику обслуживания. Только этот путь может проверить подлинность и целостность, и только последующие проверки заявок могут решить авторизацию. Отказ декодера размыть эти задания является функцией безопасности.