Смягчает ли OAuth «состояние» какие-либо действительно опасные атаки?

Question

Я использовал OAuth Playground , чтобы лучше понять поток OpenID Connect, и он говорит о проверке параметра state:

Пользователь был перенаправленобратно к клиенту, и вы увидите несколько дополнительных параметров запроса в URL:

?state=7ymOWcwttpCfDNcs&code=Tav2TPBjSNvR8aowA3oe

Поскольку злоумышленник может создать запрос GET, который выглядит примерно так:Злоумышленник может предоставить вашему приложению коды авторизации нежелательной почты.Сначала необходимо убедиться, что параметр состояния соответствует сеансу этого пользователя, чтобы быть уверенным, что вы инициировали запрос и отправляете только тот код авторизации, который предназначен для вашего клиента.

На основании этогоПо объяснению, кажется, что единственная «атака», которую мы предотвращаем с помощью параметра состояния, - это та, в которой злоумышленник отправляет нашему приложению неверные коды, мы проверяем неверный код на сервере авторизации и получаем отказ.

Но на самом деле это не очень-то сильно навлекает злоумышленника или причиняет нам большой вред: мы просто делаем несколько дополнительных http-запросов к серверу авторизации, которые нам бы не понадобились, если бы мы отклонилинемедленно запросить на нашем сервере, когда состояние не соответствует.

Мой вопрос: правильное ли мое понимание, или я упускаю более последовательный вектор атаки, который state предотвращает?

Answer 1

Мой вопрос: верно ли мое понимание

Нет

Почему?

Спецификация OAuth 2.0 предоставляетТвердый пример того, что можно сделать с помощью поддельных перенаправлений.Во-первых, из определения ,

состояние : РЕКОМЕНДУЕТСЯ.Непрозрачное значение, используемое клиентом для поддержания состояния между запросом и обратным вызовом.

Состояние помогает связать запрос на авторизацию с ответом на авторизацию и предотвратить подделку межсайтового запроса.Думайте, что у вашего клиента есть URL перенаправления, который получает ответ.Что делать, если злоумышленник перенаправит ваш клиент с действительным токеном доступа (при использовании неявного потока).А что если этот токен доступа разрешает доступ к действительному ресурсу, принадлежащему злоумышленнику на том же сервере ресурсов, который вы используете. OAuth 2.0 (RFC6749) дает хороший пример для этого на банковских реквизитах .

CSRF-атака на URI перенаправления клиента позволяет злоумышленнику ввести свой собственный код авторизации или токен доступа, что может привести к тому, что клиент будет использовать токен доступа, связанный с защищенными ресурсами злоумышленника, а не жертву(например, сохранить информацию о банковском счете жертвы на защищенном ресурсе, контролируемом злоумышленником).

Параметр State предотвращает этот тип атак.Кроме того, я приветствую вас на RFC6819 - Модель угроз и соображения безопасности .Он включает в себя множество векторов атак и измерения счетчиков, которые можно было бы использовать при использовании OAuth 2.0.В него входит раздел о CSRF-атаках и использовании состояния .