Понимание защиты OAuth2 csrf - PullRequest
0 голосов
/ 15 мая 2019

У меня три сервера

  • фронтенд-сервер-1
  • фронтенд-сервер-2
  • backend-сервер

И три домена

  • client-1.com
  • client-2.com
  • api.com

Один сервер соответствует одному домену.

Другие условия:

  • Пользователь может использовать client-1.com или client-2.com, которые работают с api.com под капотом.
  • Все запросы к api.com поступают из браузера пользователя
  • Все запросы ajax содержат заголовок X-Auth-Token вместо файлов cookie.
  • Все приложения OAuth2 ДОЛЖНЫ быть направлены на api.com (поэтому они могут перенаправлять только на api.com/auth/...)
  • Все запросы проходят через HTTPS

Я много читал об OAuth2 csrf, поэтому разработал более подходящий поток аутентификации и хочу быть уверен, что он не атакует.

  1. Браузер отправляет ajax-запрос POST на "api.com/auth-begin" с параметром "redirect_to = client-N.com / oauth / complete"
  2. Backend-сервер проверяет, разрешен ли redirect_to адрес и отвечает с

    • auth-токен (если пользователь не вошел в систему, то это анонимный токен для дальнейшей аутентификации, в противном случае это его фактический токен аутентификации)
    • CSRF-токен
    • oauth-redirect-url с указанием состояния = urlencoded (redirect_to = redirect_to & csrf-token = token) (например, github.com/oauth2/...")
  3. Браузер сохраняет токен авторизации и токен csrf в SessionStorage client-N.com

  4. Браузер переходит на oauth-redirect-url (сторонний сайт)

  5. Ответы сторонних сайтов с перенаправлением на "api.com/oauth2-process?state=my_state&3rd-party-code=my_code"

  6. Браузер переходит к "api.com/oauth2-process?state=my_state&3rd-party-code=my_code"

  7. Backend-сервер считывает «redirect_to» из «state» и перенаправляет ответы на «client-N.com» с «state» и «кодами сторонних производителей»

  8. Браузер переходит на перенаправленную страницу "client-N.com"

  9. Браузер отправляет запрос ajax POST на "api.com/auth-end" с

    • параметр "состояние"
    • параметр "сторонний код"
    • заголовок X-Auth-Token (токен авторизации из SessionStorage)
    • заголовок X-Csrf-Token (csrf-токен из SessionStorage)
  10. Бэкэнд-сервер проверяет, соответствует ли "csrf-token" из "состояния" в равной степени X-Csrf-Token

  11. Backend-сервер завершает работу oauth2 путем обмена сторонним кодом на сторонний токен, генерирует новый X-Auth-токен, если пользователь вошел в систему, в противном случае токен остается прежним и отвечает браузеру с помощью X-Auth-Token

Итак, главный вопрос: есть ли способ атаковать этот поток аутентификации?

...