Неправильная проверка криптографической подписи в ueberauth Guardian позволяет неаутентифицированному злоумышленнику отозвать сеанс жертвы с помощью поддельного токена. Guardian.revoke/3 в lib/guardian.ex декодирует предоставленный токен с помощью peek/1, который не выполняет проверку подписи (он декодирует только заголовок JWT и полезную нагрузку в формате Base64). Результирующие непроверенные утверждения пересылаются непосредственно в обратный вызов отзыва настроенного модуля токена и обратный вызов on_revoke реализации, приемник изменения состояния.
Родственные операции обновления/2 и обмена/4 сначала вызывают decode_and_verify, поэтому подпись проверяется до того, как что-либо воздействует на утверждения; revoke/3 — единственный путь изменения состояния, который действует на утверждения без проверки подписи. Злоумышленник, который знает или догадывается об идентификационных значениях утверждений жертвы (jti, sub), может подделать JWT, содержащий эти утверждения, подписать его произвольным ключом и отправить его в любую конечную точку, которая передает токен, предоставленный вызывающей стороной, в Guardian.revoke/3 (стандартный шаблон выхода из системы или отзыва сеанса). Когда модуль токена изменяет состояние, указанное в утверждениях (удаление белого списка или вставка черного списка, например хранилище в стиле GuardianDb), законный сеанс жертвы удаляется.
Это отказ в обслуживании при отзыве сеанса без аутентификации; злоумышленнику никогда не понадобится секрет подписи. Эта проблема затрагивает Guardian: с версии 1.0.0 до 2.4.1.
Показать оригинальное описание (EN)
Improper Verification of Cryptographic Signature in ueberauth guardian allows an unauthenticated attacker to revoke a victim's session with a forged token. Guardian.revoke/3 in lib/guardian.ex decodes the supplied token with peek/1, which performs no signature verification (it only base64-decodes the JWT header and payload). The resulting unverified claims are forwarded directly to the configured token module's revoke callback and the implementation's on_revoke callback, a state-mutating sink. The sibling operations refresh/2 and exchange/4 both call decode_and_verify first, so the signature is checked before anything acts on the claims; revoke/3 is the only state-mutating path that acts on claims without verifying the signature. An attacker who knows or guesses a victim's identifying claim values (jti, sub) can forge a JWT carrying those claims, sign it with an arbitrary key, and submit it to any endpoint that funnels a caller-supplied token into Guardian.revoke/3 (the standard logout / session-revocation pattern). When the token module mutates state keyed by the claims (whitelist deletion or blacklist insertion, for example a GuardianDb-style store), the victim's legitimate session is evicted. This is an unauthenticated session-revocation denial of service; the attacker never needs the signing secret. This issue affects guardian: from 1.0.0 before 2.4.1.
Характеристики атаки
Последствия
Строка CVSS v4.0