Узкое место OAuth-2.0 в Кодексе авторизации Протокол авторизации гранта

Рассмотрите протокол предоставления протокола авторизации OAuth-2.0.Узкое место OAuth-2.0 в Кодексе авторизации Протокол авторизации гранта

Как описано в стандартном проекте http://tools.ietf.org/html/ietf-oauth-v2-26 на Figure 3 : Authorization Code FlowClient получает маркер от имени Authorization Code получил от User-Agent. Предположим, что User-Agent намеренно отправляет неверные коды в Client. Если Authorization Server защищает от brute force способ получения Access Token путем запрета Client в течение некоторого разумного промежутка времени (по IP или по Redirection URI имени хоста). Если в нашем случае предполагается, что Client обрабатывает орды запросов от нескольких разных User-Agent's, Client прекратит обслуживать всех своих пользователей, если существует только один злонамеренный.

Таким образом, Client становится узким местом в ситуации, описанной выше.

==== EDITED ==== Любые идеи о том, как избежать проблемы с узким местом?

источник

2012-05-24 Artem Oboturov

Я полагаю, вы спрашиваете: «Как избежать этой проблемы и НЕ раскрывать Код авторизации для User-Agent?"

Это невозможно. Запрос OAuth проходит через браузер пользователя, поэтому вы не можете запретить пользователю выставлять код авторизации.

Если вы являетесь жертвой такого нападения, я предлагаю ввести в ваш клиент такую же защиту, что поставщик OAuth помещает их в свой сервер авторизации. А именно, прекратить передачу новых авторизационных кодов от агента-пользователя, злоупотребляющего вашей службой. Если они отправляют больше, чем, скажем, 3 недействительных токена в час, запретите их на час или два (по IP-адресу). Конечно, это может привести к тому, что вы запретите доступ к вашему сайту с прокси-серверов из-за одного плохого пользователя на прокси-сервере, но это жизнь.

источник

2012-05-25 17:47:55

Речь идет о «токене доступа», но наша ситуация довольно громоздка для нас, потому что существует один тип Auth, реализованный поставщиком Auth, который мы обязаны использовать. Я удалю фразу о «Auth Token», потому что это вводит в заблуждение и компенсирует точку моего вопроса. Спасибо за ответ. –

Спасибо за разъяснение. Я думаю, что ответ остается тем же, хотя ... единственный способ предотвратить эту атаку на вашем клиенте - реализовать тот же тип защиты, что и поставщик OAuth, который предотвращает использование вашего клиента в этих атаках с использованием грубой силы. –

Если вы просто используете OAuth для * авторизации *, и пользователь уже прошел аутентификацию (например, через имя пользователя/пароль), вы можете потребовать проверки подлинности перед тем, как позвонить в OAuth. Затем вы можете ограничить количество запросов OAuth на каждого пользователя, прошедшего проверку подлинности, и использовать CAPTCHA или аналогичные, чтобы затруднить создание пользователей. В принципе, вы можете сделать это намного сложнее, если машины используют ваш сервис, но, вероятно, не делают это невозможным. В какой-то момент нападавшие могут решить, что есть более простые цели и оставить вас в покое :) –

Узкое место OAuth-2.0 в Кодексе авторизации Протокол авторизации гранта

ответ

Смежные вопросы