В библиотеке liboauth2 исправлены две уязвимости: подмена запросов к внутренним ресурсам и приём ключей в заголовке токена

vulnerability

Разработчики проекта OpenIDC выпустили обновление библиотеки liboauth2 до версии 2.3.0, в котором закрыты две уязвимости, связанные с обработкой JWT-токенов и проверкой подписей. Обе проблемы получили средний уровень опасности по шкале CVSS 4.0 - 5,1 балла каждая - и затрагивают все версии библиотеки до указанной. Первая уязвимость (CVE-2026-54430) позволяет атакующему инициировать запросы от сервера к произвольным внутренним адресам, а вторая (CVE-2026-54431) - обмануть механизм проверки подтверждения владения ключом (DPoP), заставив библиотеку принять токен, в заголовке которого содержится закрытый ключ.

Детали уязвимостей

Суть первой уязвимости кроется в функции "oauth2_jose_jwks_aws_alb_resolve()", отвечающей за верификацию токенов для балансировщиков нагрузки AWS Application Load Balancer. Эта функция считывает из непроверенного JWT-заголовка параметры "signer" и "kid". Если значение "signer" совпадает с ARN (Amazon Resource Name), настроенным в конфигурации, то значение "kid" без какой-либо санитизации дописывается к базовому URL балансировщика и сразу же отправляется HTTP GET-запрос - ещё до проверки подписи токена. Таким образом, злоумышленник может подставить в "kid" внутренний путь (например, "/admin/delete" или любой другой), и сервер выполнит GET-запрос к этому адресу. Это типичная атака типа Server-Side Request Forgery (SSRF) на уровне локальной сети. Поскольку запрос исходит от самого сервера, он может обращаться к служебным эндпоинтам в частной сети, которые не доступны извне.

Вторая уязвимость связана с функцией "oauth2_token_verify()", проверяющей DPoP-доказательства (Demonstrating Proof-of-Possession) - механизм, который по стандарту RFC 9449 требует удостовериться, что предъявитель токена действительно владеет закрытым ключом. В реализации liboauth2 отсутствует проверка шага 4.3.7 стандарта, предписывающего отвергать доказательства, содержащие в заголовке "jwk" (JSON Web Key) приватный ключ. Вместо этого библиотека успешно верифицирует DPoP-доказательство, даже если злоумышленник вставил в заголовок закрытый эллиптический ключ. Это означает, что атакующий может сформировать поддельное доказательство с собственным закрытым ключом и пройти проверку, не зная настоящего ключа сервера или пользователя. Такой сценарий позволяет подменить личность или получить несанкционированный доступ к ресурсам, защищённым протоколом DPoP.

Обе уязвимости были обнаружены в ходе внутреннего аудита безопасности и описаны в бюллетене проекта OpenIDC, а также зафиксированы в репозитории библиотеки на GitHub. Разработчики подчеркнули, что проблема связана с недостаточной валидацией входных данных на этапе до проверки криптографической подписи. В случае с SSRF порядок - сначала HTTP-запрос, затем проверка - делает атаку возможной даже на токены с недействительной подписью. В случае с DPoP - полное отсутствие обязательной по стандарту проверки приватного содержимого.

Для пользователей liboauth2, особенно тех, кто применяет её в инфраструктуре AWS с ALB или использует DPoP-токены, обновление до версии 2.3.0 является обязательным. Дополнительных временных мер защиты, кроме перехода на актуальную версию, не предусмотрено, так как уязвимости затрагивают саму логику работы библиотеки. Администраторам также рекомендуется проверить конфигурации на предмет возможного использования старой версии в контейнерах, CI/CD-пайплайнах или внутренних прокси-сервисах.

Выпуск патча для liboauth2 - ещё одно напоминание о том, что реализация криптографических протоколов и проверка токенов остаются критичными точками даже в библиотеках с открытым исходным кодом, имеющих определённую репутацию. Пропуск даже одного шага из стандарта (как в случае с DPoP) или нарушение порядка операций (запрос до верификации) способен свести на нет все остальные меры защиты. Разработчики OpenIDC уже включили в версию 2.3.0 необходимые проверки: теперь функция AWS ALB не отправляет HTTP-запрос, пока не убедится в подлинности подписи, а DPoP-верификатор отклоняет любые заголовки, содержащие приватные ключи. Рекомендуется как можно скорее применить обновление в средах, использующих библиотеку в связке с AWS ALB или DPoP-авторизацией.

Ссылки

Комментарии: 0