Почему URL-адрес перенаправления полностью соответствует требованиям Azure AD B2C?

Почему URL перенаправления должен полностью совпадать? Разве сопоставления на уровне домена не будет достаточно для надлежащей безопасности?

Что если бы у меня были сотни путей?

пример URL:

  1. https://myawesomesite.com/
  2. https://myawesomesite.com/account/profile
  3. https://myawesomesite.com/games/fungame/points
  4. https://www.myawesomesite.com/games/fungame/points

...

Мне нужно будет ввести 4 вышеупомянутых URL-адреса перенаправления в конфигурацию моего приложения B2C.

Источник

2 ответа

Решение

Это фактически обсуждается в RFC 6819 "Модель угроз OAuth 2.0 и соображения безопасности", разделы 4.1.5, 4.2.4 и 5.2.3.5.

4.1.5. Угроза: открыть редиректоры на клиенте

Открытый перенаправитель - это конечная точка, использующая параметр для автоматического перенаправления пользовательского агента в местоположение, указанное значением параметра, без какой-либо проверки. Если сервер авторизации позволяет клиенту регистрировать только часть URI перенаправления, злоумышленник может использовать открытый перенаправитель, управляемый клиентом, для создания URI перенаправления, который пройдет проверку сервера авторизации, но отправит "код" авторизации или токен доступа. до конечной точки под контролем атакующего.

Воздействие. Злоумышленник может получить доступ к "кодам" авторизации или токенам доступа.

Контрмеры:

o Требовать от клиентов регистрации полного URI перенаправления ( раздел 5.2.3.5). "

В разделе 5.2.3.5 говорится о случаях, когда это может быть слишком ограничительным, и в целях альтернативных решений.

Часто времена state Параметр также можно использовать для детерминированного перенаправления, как это было предложено Крисом.

Источник

Обычно (и проще всего) все запросы аутентификации содержат два URL-адреса перенаправления:

  1. Один (часто называемый URL-адресом ответа), который передается в параметре "redirect_uri", который должен быть зарегистрирован в Azure AD B2C, и на который все ответы для проверки подлинности возвращаются из Azure AD B2C в приложение проверяющей стороны. Примером этого является https://www.myawesomesite.com/oidc-signin,
  2. Другой (часто называемый обратным URL-адресом), который возвращается в параметре "state" и не требует регистрации в Azure AD B2C, к которому возвращается конечный пользователь после того, как приложение проверяющей стороны обработало проверку подлинности. ответ. Примером этого является https://www.myawesomesite.com/games/fungame/points,

Обработчик аутентификации, такой как промежуточное ПО аутентификации ASP.NET Core, управляет этими URL-адресами перенаправления.

Например, когда обработчик аутентификации создает запрос аутентификации, он кодирует текущий защищенный URL (например, https://www.myawesomesite.com/games/fungame/points) в параметре запроса "state".

Чтобы этот URL-адрес не был изменен, параметр "состояние" должен быть защищен с использованием шифрования или подписи.

Когда обработчик аутентификации обрабатывает ответ аутентификации, предполагая, что это успешный ответ, он создает идентификационный файл cookie и перенаправляет конечного пользователя из https://www.myawesomesite.com/oidc-signin на первоначально защищенный URL в параметре ответа "состояние".

Источник
Другие вопросы по тегам