OAuth2 Поток агента пользователя + двухсторонний OAuth - PullRequest
1 голос
/ 21 декабря 2010

У меня есть 2 вопроса о потоке агента пользователя OAuth2. (текущий проект RFC потока пользовательского агента OAuth2 находится здесь: http://tools.ietf.org/html/draft-ietf-oauth-v2-11#section-2.2)

1)

Шаг C: токен доступа должен быть указан во фрагменте, потому что только пользовательский агент (браузер) будет иметь к нему доступ. Почему это такая проблема, если она попадет на сторону сервера (если есть какая-либо сторона сервера) Существуют также простые обходные пути, чтобы клиентская сторона могла передать его на серверную (cookie, скрытые поля, ...)

2)

Я хочу реализовать поток агента пользователя OAuth2, но с двухсторонней версией (достаточно request_token, приложение-потребитель может выступать в роли его пользователей, поэтому нет необходимости аутентифицировать пользователя у поставщика услуг)

У меня есть один серьезный пробел в безопасности, связанный с потоком пользовательского агента OAuth2 и двухсторонней версией:

Веб-браузер обрабатывает все перенаправления. Это означает, что, хотя поставщик услуг считает, что он отправляет пользователя на указанный хост и домен, этот хост и домен тривиально для пользователя, чтобы перенаправить его на свой компьютер - или куда-либо еще, путем настройки своих настроек DNS или / etc / hosts файл.

Давайте посмотрим на это с 3-мя ножками и с 2-мя ножками:

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

  • При двухстороннем OAuth, однако: Злоумышленник может легко настроить локальный хост (/ etc / hosts) с доменом приложения невинного потребителя и получить запрос request_token. Пользователь не имеет к этому никакого отношения. Теперь злоумышленник может совершать звонки от имени всех пользователей невинного потребительского приложения. У кого-нибудь есть идеи, как устранить этот пробел?

Привет, Chielus

...