Инструменты разработчика · Декодер JWT
Проверка аудитории и эмитента: предотвращение повторного воспроизведения JWT в другом месте
· Почему это важно
JWT аутентификация безопасность
Токен, выпущенный для одного сервиса, может быть представлен другому, использующему того же эмитента. В этом посте объясняется, как проверки aud и iss останавливают это и как читать оба утверждения в токене.
Служба B принимает токен, предназначенный для службы A — межсервисное воспроизведение, которому не препятствует действительная подпись.
Подпись может быть действительна для токена, выданного другой службе. Если несколько API доверяют одной и той же платформе идентификации, но игнорируют контекст получателя, учетные данные, предназначенные для службы A, могут быть воспроизведены в службе B. Сама по себе криптографическая целостность не дает ответа на вопрос, кто должен их использовать.
ToolAcre может выявить `iss` и `aud`, чтобы разработчик мог обнаружить очевидное несоответствие. Эти строки остаются непроверенными до тех пор, пока подпись не будет успешной, и инструмент браузера никогда не выполняет эту проверку. Фактический сервер ресурсов должен обеспечивать как свои отношения с эмитентом, так и целевую аудиторию.
iss — привязка токена к эмитенту, которому доверяет ваша служба, и почему совпадения строк недостаточно без привязки ключей
`iss` идентифицирует объект, которому утверждения полезной нагрузки выдали токен. Верификатору нужен точный ожидаемый эмитент в своей собственной конфигурации, и он должен связать этот идентификатор с правильным отношением обнаружения ключа. Сравнение текста без криптографической привязки оставляет злоумышленнику возможность скопировать ожидаемую строку.
Декодер описывает `iss` как «кто создал токен», но это зарегистрированное значение, а не вывод о вставленном значении. Читаемый текст издателя является полезным свидетельством для отладки конфигурации. Он не может выбрать произвольный источник ключей или аутентифицировать себя.
aud — строка или массив с именами предполагаемых получателей и правилом, по которому проверяющий должен найти себя в ней.
`aud` называет предполагаемых получателей и может отображаться как одна строка или коллекция. Политика сервера ресурсов должна найти себя в аутентифицированном значении, используя точные правила сравнения, требуемые его профилем. Он не должен принимать токен только потому, что в списке указан какой-либо другой знакомый сервис.
ToolAcre переносит массивы как текст JSON в свою таблицу утверждений, сохраняя их видимую структуру для проверки. Он не знает текущий идентификатор API и не может определить совпадение. Это преднамеренное отсутствие не позволяет универсальному декодеру изобретать контекст авторизации, которым он не обладает.
azp и область действия — утверждения OpenID Connect и OAuth, которые определяют, кто и для чего может использовать токен.
`azp` и `scope` могут добавлять контекст об авторизованной стороне и запрошенных разрешениях в профилях, которые их определяют. Они не заменяют проверку аудитории, эмитента или подписи. Имя области — это утверждение, а не разрешение, пока сервер ресурсов не сопоставит аутентифицированное значение со своей собственной политикой.
Текущий декодер рассматривает их как утверждения, специфичные для приложения, поскольку его таблица зарегистрированных описаний охватывает семь имен ядер. Он отображает их значения, но не предоставляет семантику OpenID Connect или OAuth. Прежде чем использовать их при принятии решения, ознакомьтесь с соответствующим профилем и контрактом с поставщиком.
Паттерн «запутанный депутат» — как легитимный токен становится атакой, когда аудитория не проверяется
Растерянный депутат использует законную власть в непредвиденном контексте. Токен, принятый не той службой, может инициировать именно этот шаблон, даже если никто не подделывал подпись. Проверка аудитории ограничивает возможности применения подтвержденных утверждений, а проверка издателя ограничивает количество утверждений, которые учитывает служба.
Вот почему общего флага «подпись действительна» все равно будет недостаточно. Авторизация зависит от получателя и операции. ToolAcre полностью позволяет избежать этой двусмысленности, сообщая об отсутствии результатов проверки, предоставляя службе-потребителю возможность объединить криптографию с контекстной политикой.
Рабочий пример — чтение iss и aud из двух токенов в декодере ToolAcre JWT и принятие решения, какой сервис должен принимать каждый
Создайте два безобидных токена, декодированные полезные данные которых различаются только в `aud`: один называет `service-a`, другой `service-b`; оба претендуют на одного и того же эмитента. ToolAcre делает разницу видимой. Верификатор службы A не должен принимать ни того, ни другого только из этого отображения, а должен отклонять аутентифицированную аудиторию службы B.
Затем выполните обратное упражнение с двумя строками эмитента. Одного ожидаемого текста недостаточно, если только при проверке не используются ключи, доверенные этому эмитенту. Эти примеры отделяют проверку от принятия и показывают, почему копирование правильных утверждений в сфабрикованный токен не меняет доверенную политику.
Чего это не касается — проверку подписи, которую декодер никогда не выполняет; Проверки aud и iss имеют значение только после того, как подпись сохраняется.
Проверки аудитории и эмитента имеют значение только после того, как криптографическая проверка установит, что защищенные байты соответствуют материалу доверенного ключа. ToolAcre не выполняет никакой этой проверки. Его выходные данные не могут доказать, что заявка сохранилась без изменений или что ее автором является известный эмитент.
Он также не извлекает метаданные, не выбирает ключи и не сравнивает настроенных получателей. Используйте серверные тесты и журналы, чтобы доказать отказ не тому эмитенту и не той аудитории. Визуальное совпадение в декодере — это ключ к отладке, но никогда не является достаточным доказательством авторизации.
Вывод: проверьте, для кого оно предназначено, а не только кто его подписал — декодер ToolAcre JWT показывает утверждения aud и iss, которые вам нужно сравнить.
Проверьте, для кого предназначен токен, а не просто имя, подписанное на нем. Надежный поток аутентифицирует защищенные байты в рамках отношений независимого доверенного эмитента, затем требует приемлемую аудиторию и применяет правила авторизации для конкретной службы.
Используйте ToolAcre, чтобы прочитать безопасные тестовые значения и сформулировать следующую проверку на стороне сервера. Не выбирайте ключи проверки из недоверенного заголовка или данных утверждения и не превращайте отображаемые `iss`, `aud`, `azp` или `scope` в предоставление без полного доверенного потока.