Каково значение "code_verifier" в PKCE OAuth 2.0?
В PKCE я понимаю, что code_verifier используется для создания запроса кода, и позже это значение code_verifier проверяется сервером авторизации для завершения процесса PKCE.
Насколько чувствительно это значение code_verfier? Нужно ли хранить это значение в секрете? Какие все атаки может выполнить злоумышленник, если утечка этого значения?
1 ответ
code_verifier действительно чувствителен: это механизм, с помощью которого клиент при вызове к конечной точке токена доказывает, что именно он инициировал запрос авторизации.
Это значение должно храниться в секрете, также см. Ниже.
Утечка позволила бы злоумышленнику выдать себя за (общедоступного) Клиента при обращении к конечной точке токена Сервера авторизации, таким образом получив токены, предназначенные для реального Клиента.
Обратите внимание, что даже когда не используется какое-либо преобразование (хэширования) в code_verifier но отправь как plain в code_challenge в запросе на авторизацию злоумышленнику все равно будет трудно перехватить обратный вызов на URI перенаправления, поскольку ему также придется перехватить исходящий запрос.
Но в целом code_verifier следует хэшировать с помощью SHA256 в code_challenge поэтому даже при перехвате запроса злоумышленник не может вывести code_verifier,
Из раздела 1 RFC:
Общедоступные клиенты OAuth 2.0 [RFC6749] подвержены атакам с перехватом кода авторизации.
В этой атаке злоумышленник перехватывает код авторизации, возвращаемый из конечной точки авторизации, в пределах пути связи, не защищенного протоколом TLS, например, при обмене данными между приложениями в операционной системе клиента.
После того, как злоумышленник получил доступ к коду авторизации, он может использовать его для получения токена доступа.
...
Чтобы смягчить эту атаку, это расширение использует динамически созданный криптографически случайный ключ, называемый "верификатором кода". Для каждого запроса авторизации создается уникальный верификатор кода, и его преобразованное значение, называемое "запрос кода", отправляется на сервер авторизации для получения кода авторизации. Затем полученный код авторизации отправляется в конечную точку маркера с помощью "верификатора кода", и сервер сравнивает его с ранее полученным кодом запроса, чтобы он мог выполнить доказательство владения "верификатором кода" клиентом. Это работает как смягчение, поскольку злоумышленник не узнает этот одноразовый ключ, поскольку он отправляется через TLS и не может быть перехвачен.
Ключевой формулировкой здесь является: "доказательство того, что клиент владеет" верификатором кода ". Это работает как смягчение, поскольку злоумышленник не узнает этот одноразовый ключ, поскольку он отправляется через TLS и не может быть перехвачен".
TL;DR:
Пара запрос кода + верификатор - это решающая вещь, которая доказывает, что клиент, запрашивающий токен аутентификации, является таким же (или ему доверяет) клиент, который запросил код авторизации в первую очередь. В случае утечки верификатора кода атака, упомянутая здесь в RFC (по сути, вредоносное приложение, использующее перекрестный обмен данными для выдачи себя за законное приложение), не смягчается, и, таким образом, цель PKCE (предотвращение такой атаки) предотвращается.