Ами ако кодът за оторизация в 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 не препраща кодове за удостоверяване към моя бекенд сървър, като гарантира, че заявката не е ИНИЦИИРАНА от лош актьор. Не виждам как помага с този лош актьор, който наблюдава този код за удостоверяване и прави своя собствена заявка (curl) към моя бекенд сървър. - 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