PKCE в OAuth: проверка code verifier и защита authorization code
Как PKCE связывает обмен кода с клиентом, зачем нужен S256 и почему PKCE не заменяет проверку redirect URI и токенов.
Коротко о главном
- Чем опасно
- Использование чужого authorization code при отсутствии необходимой проверки.
- С чего начать защиту
- Используйте поддерживаемый клиент с PKCE S256 и случайным verifier для каждого потока.
- Как подтвердить
- Нужны ручной аудит и проверка реализации. Отсутствие находок во внешнем скане не подтверждает безопасность.
В этой статье
- Продукт
- Веб-приложения
- Оценка риска
- Уровень зависит от конфигурации
Как проверить и что учитывать
Нужна ручная проверка
Для подтверждения нужны анализ реализации и проверки на согласованном тестовом контуре. Публикация не означает автоматическое обнаружение этого сценария FindRisk. Не делайте вывод о наличии уязвимости только по одному внешнему признаку: подтвердите результат в настройках и версии компонента.
Что нужно для подтверждения
В тестовом окружении обменяйте код с правильным, отсутствующим и неверным verifier. Только согласованный обмен должен пройти; повтор кода и попытка обхода обязательного PKCE отклоняются.
Ограничения вывода
- Внешний ответ не раскрывает все роли, обработчики и настройки внутренних компонентов.
- Используйте только свои системы или письменное разрешение владельца; нагрузочные проверки согласуйте отдельно.
Что это за уязвимость
Клиент создаёт случайный verifier и передаёт производный challenge при авторизации. При обмене кода сервер проверяет соответствие, уменьшая риск использования перехваченного кода без verifier.
Когда возникает риск
Защита зависит от обязательности проверки на authorization server и корректной привязки к запросу. Verifier нельзя публиковать в URL авторизации или логах; PKCE не удостоверяет личность пользователя само по себе.
Возможные последствия
Как PKCE связывает обмен кода с клиентом, зачем нужен S256 и почему PKCE не заменяет проверку redirect URI и токенов.
- Использование чужого authorization code при отсутствии необходимой проверки.
- Ослабление потока при разрешении downgrade без PKCE.
Как защитить приложение
Исправляйте причину в обработчике, а не только внешний симптом.
- Используйте поддерживаемый клиент с PKCE S256 и случайным verifier для каждого потока.
- На сервере требуйте соответствующий verifier и не допускайте downgrade для клиентов, обязанных применять PKCE.
- Дополнительно проверяйте redirect URI, issuer и аудиторию токенов.
Как безопасно проверить исправление
В тестовом окружении обменяйте код с правильным, отсутствующим и неверным verifier. Только согласованный обмен должен пройти; повтор кода и попытка обхода обязательного PKCE отклоняются.
Оценка риска и границы сканирования
Средний уровень — ориентировочная редакционная оценка, не CVSS подтверждённой находки. Для конкретной системы приоритет зависит от доступных данных, полномочий и компенсирующих мер; последствия могут быть значительно серьёзнее.
Отсутствие находки во внешнем скане не доказывает безопасность реализации. Проверяйте сценарии после входа, альтернативные маршруты и внутренние сервисы.
Как проходит проверка
Для подтверждения нужны анализ реализации и проверки на согласованном тестовом контуре. Публикация не означает автоматическое обнаружение этого сценария FindRisk. Автоматический результат показывает внешний признак риска и требует проверки специалистом с учётом конкретной конфигурации.
Проверить другие внешние рискиЧто делать после обнаружения
- Зафиксируйте затронутый сценарий и сохраните журналы без токенов и персональных данных.
- Ограничьте проблемный обработчик, оцените доступные данные и назначьте владельца исправления.
- Устраните первопричину и добавьте регрессионную проверку на тестовых данных.
Частые вопросы
Что означает риск «PKCE в OAuth»?
Как PKCE связывает обмен кода с клиентом, зачем нужен S256 и почему PKCE не заменяет проверку redirect URI и токенов.
Можно ли подтвердить проблему только внешней проверкой?
Для подтверждения нужны анализ реализации и проверки на согласованном тестовом контуре. Публикация не означает автоматическое обнаружение этого сценария FindRisk. Итог нужно сопоставить с конфигурацией, версиями и правами доступа на вашем сайте.
Что сделать в первую очередь?
Используйте поддерживаемый клиент с PKCE S256 и случайным verifier для каждого потока.