В потоке кода авторизации OAuth 2.0 с PKCE что мешает перехватить вызов кода при первом обращении к серверу авторизации?

Question

Представьте себе эту атаку

1. Злоумышленник перехватывает первый вызов на сервере авторизации, затем у него есть вызов кода. (шаг 1 на диаграмме)
2. Теперь злоумышленник перехватывает ответ от сервера авторизации с кодом авторизации. (шаг 2 на диаграмме)
3. Затем злоумышленник может отправить POST код авторизации и верификатор кода, чтобы получить токен доступа. (шаг 3)

См. эту схему: flow:

Вопросы

1. Что мешает злоумышленнику перехватить первый звонок на сервер авторизации? Это то, что должно сделать код авторизации + PKCE более безопасным, чем неявный поток.

2. Возможно, не имеет значения, перехвачен ли вызов, потому что вызов кода хешируется и, следовательно, злоумышленник не имеет кода-верификатора, необходимого для второго вызова. Но что, если код-вызов не хэшируется?

Answer 1

PKCE предназначен для устранения угрозы утечки токена / кода авторизации с URL-адреса, что относительно вероятно по сравнению с злоумышленником, перехватывающим трафик SSL c:

• URL-адреса видны в адресная строка
• URL-адреса сохраняются в истории браузера
• На собственных платформах можно зарегистрировать несколько приложений для использования одной и той же пользовательской схемы URI

Тем не менее, его рекомендовал, чтобы вызов кода был SHA256 ha sh верификатора кода, поэтому даже если злоумышленник перехватит вызов кода, он не сможет завершить обмен токеном, не имея возможности отменить SHA256.

Также см .: Что на самом деле защищает PKCE?

Answer 2

PKCE предназначен для того, чтобы гарантировать, что клиент, который запросил пользователя для аутентификации, это тот же самый клиент, который обменивает код авторизации для токена доступа.

Вся связь с сервером авторизации использует HTTPS, go трудно перехватить. Но некоторые мобильные платформы позволяют (вредоносным) приложениям регистрировать тот же redirect_uri, что и законный клиент. Это означало, что когда сервер авторизации перенаправлялся обратно к клиенту с кодом авторизации, с кодом вызывался бы и законный клиент, и злонамеренный клиент. Это позволило злонамеренному клиенту обменять код на токен доступа, поскольку проверка подлинности клиента не выполняется.

PKCE решает эту проблему путем включения code_challenge в запрос проверки подлинности, который представляет собой ha sh средства проверки кода. , Затем требуется фактический верификатор в вызове обмена токеном. Вредоносный клиент не имеет верификатора и поэтому не может аутентифицировать себя и, следовательно, не обменивать код на токен.