Серьезная проблема с повторной игрой Live Connect OAuth2? Почему разрешающий код разрешен для использования более одного раза?

Question

Во-первых, спасибо за ваше время. Я серьезно беспокоюсь о API OAuth2 от Live Connect.

Следую за этим и используя DotNetOpenAuth для реализации/интеграции аутентификации/авторизации LiveId для нашей федеративной идентификации & системы управления доступом.

http://msdn.microsoft.com/en-us/library/live/hh243647.aspx#authcodegrant

Все работает отлично в течение довольно длительного времени. Но теперь у меня серьезные проблемы при исправлении проблемы с повторной игрой для модуля входа в LiveId. Давайте рассмотрим поток предоставления авторизационного кода из указанной статьи.

«* 4. Пользовательский агент вызывает клиента с URI перенаправления, который включает в себя код авторизации и любое локальное состояние, предоставленное клиентом. Например: ... Callback.htm? Code = AUTHORIZATION_CODE. 5. Клиент запрашивает токен доступа с конечной точки маркера сервера авторизации с использованием учетных данных своего клиента для аутентификации и включает код авторизации, который был получен на предыдущем шаге. Клиент включает URI перенаправления, который использовался для получения кода авторизации для проверка. * "

Сразу после шага 4, сервер Live Connect OAuth2 возвращается к моей конечной точке обратного вызова с кодом авторизации &, например:

https://ssss.myapp.com:443/liveid/consume.idp?code=406dd558-0cda-50cc-bd37-d964ec29fbb3&state=uvygsnd3gba0jwi315kdyccs

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

1. Пользователь А при входе в моем приложении, выбрал LiveID подписать в, то он перенаправляется на страницу входа LiveID. Затем он вошел в систему, сервер Live Connect OAuth2 вернулся в конечную точку обратного вызова с кодом = xxx & state = yyy ... пользователь A затем использовал этот код авторизации для получения токена доступа ...

2. User B при регистрации в моем приложении, выберите LiveId для входа в систему, затем он зашел на страницу входа в систему LiveId. Живой сервер Connect OAuth2 теперь возвращает с кодом = KKK & состояния = ггг

Если я на этот раз, использовать некоторые инструменты, такие как WebScarab для захвата ответа/запроса, а затем изменить отдачу от сервера oauth2 к коду = ххе & state = ggg (старый код авторизации был предоставлен пользователю A, а не B). Затем после этого запрос на токен доступа, использующий этот код авторизации повтора, проходил плавно. И угадай что? Я получил снова ACCESS TOKEN, который был предоставлен пользователю A раньше ... и, наконец, пользователь B может войти в мое приложение как пользователь A.

Обратите внимание, что применяя те же атаки, что и выше, для сервера Google OAuth2 , Я получил ошибку плохого запроса с сервера, код авторизации Google OAuth2 никогда не мог использоваться более одного раза. И поток кода или точно, реализация для входа в систему Google &. Вход в LiveId точно такой же.

Я использовал DotNetOpenAuth.OAuth2.WebServerClient для реализации потока аутентификации OAuth2 как для Google & LiveId. Опять же, точно такой же код, но сервер Google OAuth2 вернул «плохой запрос», когда код авторизации повторно используется, но LiveId вернул старый токен доступа предыдущего пользователя.

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

Большое спасибо, Phuc Le.

Answer 1

OAuth 2 спекло quite clear here:

Если код авторизации используется более чем один раз, сервер авторизации должен отклонить запрос и следует отменить (если это возможно) все маркерами ранее выпущенные на основе этого кода авторизации ,

Это для exact reasons Вы упомянули выше.

В вашем случае вы должны notify your provider этой проблемы.

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