Инструменты разработчика · Декодер JWT
Атака alg:none и путаница ключей: почему верификаторы должны закреплять алгоритмы
· Почему это важно
JWT безопасность криптография
Если верификатор позволяет токену выбирать собственный алгоритм, злоумышленник может выбрать его без него или заменить RSA на HMAC. В этом посте описаны как атаки, так и правила, которые их предотвращают.
Токен, который подтвердил себя: как поле заголовка стало поверхностью атаки
Метка алгоритма находится внутри входа токена, контролируемого злоумышленником. Если верификатор рассматривает эту метку как разрешение на выбор любого доступного режима проверки, токен начинает влиять на правило, используемое для оценки самого себя. ToolAcre предоставляет метку именно для того, чтобы рецензенты могли ее увидеть, но никогда не действует с ней криптографически.
Безопасное направление — обратное: конфигурация доверенной службы определяет приемлемые семейства алгоритмов и связанные ключи, тогда входящие заголовки должны соответствовать этой политике. Панель декодирования не может обеспечить эту политику, и ее нельзя ошибочно принимать за защиту просто потому, что она выделяет подозрительное значение.
Репозиторий помечает alg:none, но не устанавливает историю спецификаций незащищенных JWT.
Реализация рассматривает `alg: none` как неподписанное объявление и предупреждает, что его принятие приведет к принятию произвольного содержимого. Он также отдельно сообщает о пустом третьем сегменте. Свидетельства хранилища подтверждают отказ от такого ввода в аутентифицированных рабочих процессах; он не документирует, почему незащищенные JWT изначально были включены в спецификацию.
Таким образом, эта историческая формулировка скорее исправлена, чем придумана. Что важно с оперативной точки зрения, ясно: служба, ожидающая подписанные учетные данные, не должна позволять заголовку токена отключать проверку подписи. ToolAcre сам по себе не выполняет никакой проверки, поэтому его способность отображать `none` предназначена только для обнаружения и проверки.
Атака alg:none — удаление подписи и просьба верификатору принять пустую подпись.
Беззнаковая атака изменяет заголовок на запрос `none`, при необходимости изменяет утверждения и не предоставляет байты подписи. Каждый сегмент по-прежнему может быть синтаксически допустимым, а первые два декодируются в усовершенствованный JSON. Разрешительный верификатор превратит предпочтения злоумышленника в обход аутентификации.
У строгого верификатора нет ветки, которая повышала бы этот вход до статуса доверенного, когда требуются подписанные токены. Предупреждение ToolAcre помогает идентифицировать форму во время отладки, но чтение слова `none` не мешает серверной части принять неправильное решение. Правоприменение осуществляется там, где используются учетные данные.
Путаница ключей — представление открытого ключа как секрета HMAC, поэтому токены RS256 проверяются как HS256.
Путаница с ключами возникает, когда верификатор допускает семейства алгоритмов с несовместимыми ключевыми ролями и не может привязать каждый вариант к правильному типу ключа. Открытый ключ проверки RSA не является секретом HMAC. Обработка его байтов как одного после того, как злоумышленник изменил метку алгоритма, разрушает запланированное разделение public/private.
Для предотвращения ошибок этого класса требуется нечто большее, чем просто проверка сегмента в форме подписи. Служба должна связать ожидаемый алгоритм, тип ключа, эмитента и профиль токена с помощью доверенной конфигурации. Декодер, отображающий RS256 или HS256, не может определить, поддерживает ли серверная часть эти привязки.
Исправление — закрепить принятые алгоритмы в верификаторе и никогда не выводить их из токена.
Закрепите принятые алгоритмы в конфигурации верификатора и сохраняйте список настолько узким, насколько это позволяет контракт с эмитентом. Отклонить `none` для подписанных потоков учетных данных и отклонить несоответствия вместо того, чтобы пробовать другой алгоритм. Не извлекайте список разрешений из непроверенного заголовка или утверждения полезной нагрузки.
Поиск ключей следует тому же принципу. `kid` может выбирать среди уже доверенных кандидатов, но не должен создавать новый источник доверия. URL-адреса заголовков или встроенные ключи не должны использоваться только потому, что их запрашивает токен. Верификатор самостоятельно определяет источники.
Рабочий пример — чтение заголовка в декодере ToolAcre JWT для обнаружения alg:none и почему его обнаружение — это не то же самое, что защита.
Создайте безопасный заголовок токена, объявляющий `none`, и оставьте третий сегмент пустым. ToolAcre декодирует JSON, сообщает об объявленном алгоритме, предупреждает, что он не подписан, и отмечает отсутствие подписи. Это именно то поведение, которое ожидается от инструмента проверки.
Это упражнение не доказывает, что API отклоняет токен. Подтвердите это отдельно с помощью контролируемого отрицательного теста на соответствие фактическому проверяющему устройству и конфигурации. Если API принимает его, исправление принадлежит этой границе проверки; добавление более громкого предупреждения в декодер не защитит запросы.
Чего здесь не касается — множество исправлений, специфичных для библиотеки; обратитесь к RFC 8725 и журналу изменений вашей библиотеки.
API-интерфейсы библиотеки, настройки по умолчанию и исторические исправления различаются в зависимости от продукта и версии. Этот модуль не определяет, какие алгоритмы имен опций закрепляются в вашем стеке, и в этой статье намеренно ничего не придумывается. Прочтите текущую документацию и журнал изменений выбранной библиотеки, а затем протестируйте случаи отклонения в своем собственном наборе тестов.
Также проверьте неправильные типы ключей, неизвестные значения `kid`, отсутствующие подписи и неожиданные профили токенов. Цель — показать, что конфигурация имеет преимущество над предложениями токенов. Успешное декодирование не имеет никакого отношения к этим утверждениям о принятии, поскольку успех синтаксиса совместим с каждым вредоносным примером.
Вывод: решает верификатор, а не токен — декодер помогает вам увидеть заголовок, но вас защищает только закрепленная верификация.
Верификатор решает; жетон этого не делает. ToolAcre может раскрыть заголовок с надписью `none`, незнакомый алгоритм или неожиданный идентификатор ключа. Эта видимость помогает сортировке, но только закрепленная политика алгоритма и правильно связанные доверенные ключи предотвращают принятие.
Никогда не рекомендуется включать `none`, выбирать ключ проверки из ненадежного заголовка или рассматривать отображаемую длину подписи как проверку. Декодируйте для проверки, а затем докажите поведение отклонения и принятия на реальной криптографической границе с помощью контролируемых тестов.