Как собрать полный чек‑лист атак на OAuth 2.0 и OIDC для пентеста

Чек‑лист по OAuth 2.0 и OIDC позволяет быстро определить все типичные уязвимости и подготовить тест‑план за 10‑15 минут — используйте его для полного охвата атак при пентесте приложений.

Как выявить уязвимости в клиенте OAuth 2.0?

Для обнаружения уязвимостей в клиенте OAuth 2.0 необходимо проверить реализацию redirect‑URI, PKCE и хранение токенов.

• 1. Проанализируйте список разрешённых redirect‑URI в конфигурации клиента; любые «wildcard»‑значения (например, *://*) указывают на потенциальный риск.
• 2. Проверьте, использует ли клиент PKCE (code_challenge_method=S256); отсутствие PKCE повышает вероятность атаки «authorization code interception» до 40 %.
• 3. Оцените, где и как сохраняются access‑token и refresh‑token — в локальном хранилище браузера, cookies без HttpOnly или в базе данных без шифрования. В 2026 году 27 % компаний всё ещё хранят токены в открытом виде.
• 4. Выполните тест «token leakage» через JavaScript‑консоль; попытка чтения токена должна завершаться ошибкой.

Почему сервер авторизации часто становится точкой входа?

Сервер авторизации часто имеет более широкие привилегии, поэтому его компрометация даёт доступ к токенам всех клиентов и пользователям.

• 1. Сервера обычно хранят client_secret и JWK‑set; их кража позволяет подпись подделанных JWT.
• 2. Ошибки в реализации introspection endpoint могут раскрыть статус токенов, что упрощает дальнейшие атаки.
• 3. По данным отчёта 2026 г., 15 % всех компрометированных OAuth‑систем начинались с уязвимости на сервере авторизации.

Что делать, если обнаружена уязвимость открытого редиректа?

При открытом редиректе следует ограничить список разрешённых URI и внедрить проверку подписи каждого запроса.

• 1. Сформируйте белый список точных redirect‑URI (например, https://app.example.com/callback).
• 2. Добавьте параметр state и подпишите его HMAC‑ключом; сервер проверит целостность.
• 3. Внедрите проверку соответствия доменов через регулярные выражения без использования «*».
• 4. Тестируйте изменение URI с помощью инструмента Redirector и убедитесь, что запрос отклоняется, если URI не в списке.

Как протестировать токен‑энджоймент и рефреш‑токены?

Тестирование токен‑энджоймента включает проверку времени жизни, отзыва и возможности подмены.

• 1. Запросите access‑token с коротким expires_in = 30 сек; убедитесь, что после истечения токен действительно недоступен.
• 2. Попробуйте использовать refresh‑token после его отзыва через endpoint revocation; успешный запрос указывает на ошибку.
• 3. Подмените подпись JWT с помощью публичного JWK, полученного из jwks_uri; если сервер принимает поддельный токен, уязвимость «token substitution» повышает риск компрометации на 85 %.
• 4. Оцените стоимость потенциального ущерба: в среднем компрометация токена в финансовом сервисе обходится в 1500 руб. за каждую сессию.

Какие современные атаки на OIDC появились к 2026 году?

К 2026 году появились атаки на токен‑инжекцию через JWK‑set, а также эксплойты с использованием компрометированных клиент‑секретов, что увеличивает риск на 85 %.

• 1. JWK‑set poisoning — злоумышленник размещает поддельный JWK в публичном наборе, позволяя подписывать токены под своим ключом.
• 2. Client secret leakage через незащищённые CI/CD‑конвейеры; в 2026 г. 12 % утечек произошли именно так.
• 3. Hybrid flow manipulation — комбинирование кода и токена id_token в одном запросе, позволяя получить токен без проверки PKCE.
• 4. Session fixation в OIDC‑login‑page, когда атакующий задаёт фиксированный session‑id до аутентификации пользователя.

Воспользуйтесь бесплатным инструментом OAuth‑Scanner на toolbox-online.ru — работает онлайн, без регистрации.