Что делать, если код авторизации в Oauth просочился

Как только я успешно вхожу на сервер аутентификации, сервер перенаправляет обратно в приложение с кодом авторизации. А затем этот код авторизации используется для получения токена доступа в бэкенде. Я сомневаюсь, что кто-то видел/захватил или скопировал мой код авторизации до того, как я его использовал. Затем он также может войти в систему с моими учетными данными. Я хочу знать, правильно ли я думаю? Или я пропускаю какой-то поток безопасности в процессе.

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


authorization access-token oauth single-sign-on
person Avaneesh Kumar    schedule 27.06.2018    source источник

Ответы (2)


arrow_upward
3
arrow_downward

Вы правы: именно поэтому в OAuth 2.0 должен быть фиксированный, зарегистрированный URI обратного вызова, по которому Клиент получает код авторизации, который применяется профилями, такими как OpenID Connect. В разделе спецификации, посвященном вопросам безопасности, более подробно анализируются риски, связанные с концепцией кода авторизации: https://tools.ietf.org/html/rfc6749#section-10.5

person Hans Z.    schedule 27.06.2018
comment
поэтому, если код авторизации был захвачен после того, как сервер аутентификации отправил его пользователю, но до того, как клиент инициировал обмен, и злой пользователь, который захватил код, инициировал в своем собственном пользовательском агенте вызов клиента с кодом перед законным пользователь, клиент выполняет обмен, и теперь злой пользователь получил доступ к клиенту. обычно код отправляет небезопасный http, так как это смягчить? - person Ron87k; 27.08.2020
comment
состояние используется для предотвращения этого и криптографической привязки запроса/ответа к браузеру пользователя, см. tools.ietf.org/html/rfc6749#section-4.1.1 - person Hans Z.; 27.08.2020
comment
большое спасибо, также нашел это полезным stackoverflow.com/questions/35165793/ - person Ron87k; 31.08.2020
comment
@ Ron87k Не могли бы вы объяснить, как использование состояния снижает риск того, что злоумышленник перехватит код авторизации в истории браузера? Как вы понимаете, состояние помогает гарантировать, что мой SPA не пересылает коды аутентификации на мой внутренний сервер, гарантируя, что запрос не был ИНИЦИИРОВАН злоумышленником. Я не понимаю, как это помогает тому плохому актеру, который наблюдает за этим кодом аутентификации и делает свой собственный запрос (завиток) к моему серверному серверу. - person KFunk; 05.03.2021

arrow_upward
-2
arrow_downward

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

Затем многое зависит от вашего URI перенаправления. Если он принадлежит вашему серверу, это https (так что злоумышленник не сможет прослушать трафик), и ваш сервер не разрешает OpenRedirect – злоумышленник вероятно, не удастся захватить код.

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

Обратите внимание, что здесь я предполагаю хорошо спроектированный OAuth 2.0. Реализации OAuth 2.0, которые игнорируют требования RFC 4749, могут подвергаться множеству атак.

person Eugene Primako    schedule 27.06.2018
comment
секрет клиента не требуется, т.е. для публичных клиентов; также: злоумышленник может украсть код и представить его исходному клиенту в так называемой атаке с запутанным заместителем. - person Hans Z.; 28.06.2018
comment
Вы, безусловно, правы: общедоступные клиенты не требуют секрета клиента (или хранят его небезопасно); они также обычно имеют небезопасный uri перенаправления (т.е. с пользовательской схемой URL). Но, насколько я понял, это не тот случай, который описывает @Avaneesh Kumar. Пункт о запутанной депутатской атаке в данном случае действителен, спасибо за разъяснения. - person Eugene Primako; 28.06.2018