Last updated
Last updated
Подписи НЕ опциональный параметр, openid.sig значение ДОЛЖНО проверяться с каждым OpenID ответом, о должен быть защищен от replay attacks проверкой nonce
Надо изучать спецификацию: есть всякие нюансы, связанные с дефолтной обработкой параметра request_uri_parameter_supported
Запросили на сервере аутентификации OpenID конфигурацию: .well-known/openid-configuration
В этой конфигурации было указано, что доступен эндпоинт для регистрации своего приложения на сервере аутентификации
Пример запроса регистрации:
При регистрации в поле logo_uri указал ссылку на внутренний конфиг AWS IAM. В итоге, при авторизации через мое приложение получил AWS SecretAccessKey.
jwks_uri — для JSON Web Key Set (JWK). Этот ключ нужен на сервере для проверки JWT подписи (RFC7523).
Регистрируем свой клиент с проставлением своего uri в этот параметр. Когда сервер перейдет к обратке параметра code (ему надо будет проверить client_assertion поле), то если он сходит на наш сервак — то это ssrf
пример запроса, на котором может стриггернуться ssrf (сервер будет ожидать json в ответ)
Пусть у нас есть вот такой запрос на получение кода:
Как видите, тело запроса не содержит никаких параметров об авторизованном клиенте, что означает, что сервер берет их из сеанса пользователя. Мы даже можем обнаружить это поведение во время тестирования черного ящика.
Атака, основанная на таком поведении, будет выглядеть примерно так:
Пользователь посещает специально созданную страницу (как при типичном сценарии атаки XSS / CSRF).
Страница перенаправляется на страницу авторизации OAuth с «доверенным» «client_id».
(в фоновом режиме) Страница отправляет скрытый междоменный запрос на страницу авторизации OAuth с «ненадежным» «client_id» (мы должны иметь возможность зарегистрировать своего клиента для OAuth сервиса), что отравляет сеанс.
Пользователь утверждает первую страницу, и, поскольку сеанс содержит обновленное значение, пользователь будет перенаправлен на «redirect_uri» ненадежного клиента.
Замечание: при входе через клиент, пользователь должен одобрить этот вход. Если клиент был одобрен ранеее, сервеер может просто перенаправить его сразу. Что бы избежать этого поведения, можно добавлять к URL-запросу авторизации "prompt=consent".
RFC 8176
Этот протокол отвечает за тип 2FA. Например, в запросе пробуем acr_values
менять, например, с otp+password
на sms+password
, что приведет к проверке через SMS, а не через приложение-аутентификатор.
RFC7591: Openid Connect Registration 1.0: