Взлом авторизации XXI века: Burp против OAuth 2.0 / OIDC и JWT

Если вы тестируете современные веб-приложения, то знаете, что «взлом логина» давно перестал быть игрой в подбор паролей. Сегодня авторизация — это протоколы, редиректы, токены, подписи и тонкие согласования между клиентом, провайдером идентификации и API. Хорошая новость: всё это отлично ложится на инструментарий Burp Suite. В этой статье — живые методички для пентестеров и охотников за баунти: от перехвата потоков авторизации до классики с JWT и кейсов угонов сессий.

Запросите лишние области (scope) или иную аудиторию (audience/resource) и проверьте, что провайдер не выдал доступ сверх необходимого. Сравните полученные токены для разных клиентов, иногда «универсальные» разрешения проскакивают из-за нестрогих политик.

Редиректы и состояние: где рвётся цепь

Редиректы: белый список обратных адресов должен требовать точное совпадение схемы, хоста, порта и пути. Поддомены, маски и http в списке — предупредительный звонок. Попробуйте внедрить открытый редирект на стороне приложения и направить токен через него.

State: это защита от CSRF в авторизации. Проверьте, что параметр присутствует, меняется для каждой попытки и что сервер тщательно его валидирует. Попробуйте повторить state или применить его в другом потоке. Если принимается любое значение — это практически обход.

Паттерны тестирования в Burp: Repeater, Intruder, негативные проверки

Repeater: базовые сценарии

Соберите «цепочку» запросов и воспроизводите поток авторизации вручную. Лучшая практика — работать с «замороженными» параметрами, меняя по одному, чтобы наглядно видеть эффект. Запланируйте минимум:

• Отсутствующий/подменённый state в /authorize
• Неожиданный redirect_uri (другой путь, поддомен, схема)
• code_challenge_method=plain и невалидный code_verifier
• Повторный обмен code на /token
• Запрос областей и аудиторий сверх нормы

Intruder и Turbo Intruder: когда нужна скорость

Используйте для подбора коротких user_code в Device Flow (если видите слабую длину), для теста предсказуемых state или для попыток «угадывания» code_verifier, если он подозрительно короткий. Ограничьте частоту, чтобы не положить стенд и не вызвать блокировки. Для сложных сценариев — репозиторий Turbo Intruder с примерами скриптов.

Негативные проверки и анти-CSRF

Специально ломайте то, что «должно быть сломано»: удаляйте обязательные поля, меняйте порядок параметров, дублируйте их, отправляйте мусор вместо токенов. На стороне приложения проверяйте защиту от CSRF на страницах, принимающих результат авторизации: совпадает ли источник, проверяется ли state, нет ли скрытых автоматических сабмитов без дополнительных гарантий.

JWT Editor, Autorize/AuthMatrix, Logger++, Collaborator: тактика применения

JWT Editor

Видит и редактирует заголовки и полезные данные, помогает пересчитать подписи (где это уместно), подменить алгоритм, внести «ядовитый» kid, добавить jku/x5u. Удобно быстро циклировать варианты через Repeater. Смотрите также заметку в документации Burp: Working with JWTs.

Autorize и AuthMatrix

Идеальны для массовой проверки полномочий: создайте профили для разных ролей и токенов, прогоните типовые запросы. Если API не отличает «пользователь» от «администратор» при смене токена — найдено нарушение модели доступа. Помогут руководства и примеры: репозиторий AuthMatrix, гайд по Autorize.

Logger++

Подробный журнал запросов с фильтрами и пометками: удобно ловить странные редиректы, гонки при обмене code и совпадения токенов в неожиданных местах. Сохранённые фильтры сэкономят часы. Для базового логирования достаточно встроенного Burp Logger.

Burp Collaborator

Незаменим при проверке внешних обращений: если бэкенд тянет ваши ключи по jku, вы это увидите в журнале коллаборатора. Так фиксируются SSRF и вовсе критичные цепочки доверия к внешним JWK-наборам. Практикуйтесь на лабе: JWT bypass via jku injection.

Мини-чек-листы

Auth Code + PKCE

• Точный белый список redirect_uri (схема, хост, порт, путь)
• Наличие и проверка state и (для OIDC) nonce
• code_challenge_method=S256, разумная длина code_verifier
• Одноразовость code, привязка к client_id и сессии

Device Code

• Достаточная длина и энтропия user_code
• Привязка подтверждения к конкретной сессии/клиенту
• Безопасная обработка verification_uri_complete

JWT

• Запрет alg:none и смешения RS256↔HS256
• Безопасная обработка kid, отсутствие инъекций и обходов
• Игнор внешних jku/x5u или строгий список доверенных
• Проверка iss, aud, azp, сроков и скоса часов

Сессии и CSRF

• Один источник истины для токена: либо кука, либо заголовок
• Правильные флаги куки и отсутствие XSS-доступа к токенам
• Ротация refresh_token и отзыв при выходе
• CSRF-защита на точках приёма результатов авторизации

Как оформлять находку

Соберите минимальный воспроизводимый сценарий: шаги в Burp, скрин логов из Logger++, примеры запросов/ответов, ограничения и влияние. Важно отделять аутентификацию от авторизации в описании и показывать, какие данные и действия стали доступны. Если уязвимость требует сложной цепочки, разложите её на части и подтвердите каждую скрином или логом.

Ресурсы для погружения

• OAuth 2.0 (RFC 6749)
• PKCE (RFC 7636)
• Device Authorization Grant (RFC 8628)
• OpenID Connect Core
• JWT (RFC 7519), JWS (RFC 7515), JWK (RFC 7517)
• Burp BApp Store, Burp Collaborator

Финальные мысли

Современные SSO-схемы сложны не только для разработчиков, но и для атакующих. Это хорошая новость: строгая реализация стандартов и аккуратная интеграция сильно повышают порог. Ваша задача как тестировщика — методично проверять каждую «слабую» точку потока: редиректы, состояние, обмен кодов, подписи и сроки, хранение и смешение токенов. Burp Suite и правильный набор расширений позволяют сделать это быстро и наглядно. Удачных находок и аккуратных отчётов!