Плагин OpenID Connect OpenID Provider для Shibboleth Identity Provider не экранировал значения параметров, которые сервер идентификации возвращает клиенту через HTML-форму. Через такие параметры на странице провайдера можно разместить произвольную разметку. Затронуты все прежние версии плагина. Разработчики выпустили обновление с исправлением.
Что изменилось после обновления
Параметры ответа уходили в форму без экранирования
Спецификации OAuth 2 и OpenID Connect разрешают клиенту самому выбрать, каким способом получить ответ на запрос авторизации. Один из способов - Form Post Response Mode. В этом режиме параметры ответа кодируются как значения полей HTML-формы, а браузер автоматически отправляет её клиенту. Плагин оставлял эти значения неэкранированными.
Под удар попадали и параметры самого запроса, например state, которые до включения в форму не меняются. Атакующий мог подставить в них разметку, и сервер идентификации отдавал её от своего домена. Страница и форма становились уязвимы к внедрению.
Начиная с версии 4.1.0 страница по умолчанию связана с политикой безопасности содержимого (CSP, Content Security Policy), если соответствующее свойство конфигурации включено, а включено оно по умолчанию. Это блокирует отражённый межсайтовый скриптинг на домене провайдера. Однако внедрение разметки остаётся возможным: пользователя можно увести на недоверенный сайт, а при неявном (implicit) и гибридном (hybrid) сценариях - вместе с токенами.
Важность уязвимости разработчики оценили как среднюю или высокую. Высокой она считается для версий до 4.1.0 и для тех развёртываний, где CSP отключили после перехода на 4.1.0.
DPoP-подтверждение не привязывалось к PAR-запросу
Ещё одна уязвимость затрагивает отложенные запросы авторизации PAR (Pushed Authorization Requests) в связке с механизмом DPoP (Demonstrating Proof of Possession). Спецификация DPoP описывает два способа привязать код авторизации к ключу: через параметр запроса и через подтверждение DPoP, вложенное в сам PAR-запрос. Сервер авторизации, который поддерживает и PAR, и DPoP, обязан поддерживать оба способа.
Плагин корректно поддерживал только первый. Когда клиент присылал PAR-запрос с подтверждением DPoP, плагин проверял подтверждение, но не переносил отпечаток открытого ключа на следующие шаги. Из-за этого на конечной точке выдачи токенов можно было предъявить другой ключ DPoP вместе с кодом авторизации, полученным через PAR.
Чтобы воспользоваться этим, атакующему нужно было тем или иным путём добыть код авторизации. Кроме того, требовался доступ к конечной точке токенов от имени клиента: для конфиденциальных клиентов - учётные данные клиента, для схем с PKCE - верификатор кода. Разработчики оценили важность как низкую и отметили, что большинство развёртываний этот режим, скорее всего, не использует. Уязвимы версии с 4.2.0 по 4.3.2. Нашёл проблему Janne Lauros из CSC - IT Center for Science Ltd.
Как обновиться и что делать без патча
Исправление вышло в версии 4.3.3 плагина OIDC OP. Обновиться можно установщиком плагинов Identity Provider. Уязвимость с экранированием затрагивает все предыдущие версии, включая неофициальные сборки до 3.0.
После установки 4.3.3 значения параметров экранируются при сборке формы, поэтому разметка из запроса перестаёт исполняться на странице провайдера. CSP остаётся дополнительной мерой защиты, но полагаться только на неё больше не требуется.
Если обновление пока невозможно, режим form_post стоит исключить из разрешённых. С версии 4.1.0 это делается глобальным свойством конфигурации со списком режимов ответа или такой же настройкой профиля OIDC.SSO. С версии 3.4.0 можно требовать подписанные объекты запроса - тогда атакующий не сможет изменить значения параметров запроса авторизации.
Уязвимость с экранированием команда проекта Shibboleth нашла сама. Уведомления о безопасности secadv_20261109 и secadv_20261109a опубликованы 9 ноября 2026 года. Сведений об эксплуатации в реальных атаках в уведомлениях нет.
Ссылки
- https://shibboleth.net/community/advisories/secadv_20261109.txt
- https://shibboleth.net/community/advisories/secadv_20261109a.txt
