В OAuth-сервисе redirect_uri проверяется только по совпадению домена. Как доказать, что это позволяет перехватить код авторизации?
Нужно зарегистрировать или выбрать разрешённый домен, а затем проверить, принимает ли сервер другой URI на том же домене, но с управляемым путём, поддоменом или иной частью адреса. Если после авторизации код перенаправляется на такой URI, проверка недостаточно точна: злоумышленник может получить код и обменять его на токены, если дополнительно не сработала защита PKCE или другая проверка клиента.
Параметр redirect_uri появился в OAuth, чтобы авторизационный сервер возвращал результат только заранее согласованному клиенту. Исходная проблема заключалась в том, что без строгой проверки злоумышленник мог подставить собственный адрес и перенаправить туда код авторизации.
Практика показала, что доверие к одному домену недостаточно: открытое перенаправление, захваченный поддомен или управляемый путь могут сделать адрес фактически контролируемым. Поэтому для большинства веб-клиентов применяется точное сопоставление зарегистрированного URI; особые правила существуют, например, для loopback-адресов нативных приложений.
Пусть клиент зарегистрировал адрес на доверенном домене, но авторизационный сервер сравнивает только доменную часть. Тогда URI с другим путём, портом или поддоменом может пройти проверку, хотя обработчик этого URI контролируется злоумышленником или содержит перенаправление.
Тест должен подтвердить не только принятие изменённого URI, но и фактическую утечку результата авторизации. Без этого обнаружение слабой проверки остаётся предположением. Следует использовать тестовую учётную запись и безопасный стенд, поскольку код авторизации является чувствительным одноразовым артефактом.
Сначала фиксируют корректный зарегистрированный URI и запускают обычный сценарий авторизации. Затем поочерёдно проверяют варианты, отличающиеся путём, портом, поддоменом, схемой, регистром, кодированием символов и наличием открытого перенаправления. В каждом случае важно наблюдать, был ли запрос отклонён до выдачи результата или код действительно отправлен на изменённый адрес.
Безопасное поведение — принять только точно зарегистрированный URI с учётом правил конкретного типа клиента. Сравнение по префиксу, домену, строке до первого специального символа или «доверенному» поддомену опасно. Проверка должна выполняться на сервере, а не полагаться на скрытый интерфейс клиента.
Для публичных клиентов PKCE снижает последствия перехвата кода: злоумышленнику нужен секретный verifier, созданный первоначальным клиентом. Однако PKCE не заменяет корректную проверку redirect_uri: утечка кода остаётся нарушением границ доверия, а конфигурационные ошибки, повторное использование verifier или небезопасный клиент могут сохранить риск.
Нужно учитывать особенности нормализации URI. Разбор адреса разными компонентами может по-разному трактовать кодирование, имя пользователя, порт, IPv6 и Unicode-домены, поэтому проверять следует фактический результат авторизационного сервера и браузера, а не только визуальное сходство строк.
В тестовом OAuth-клиенте был зарегистрирован URI на корпоративном домене. Сервер принимал любой адрес с этим доменом, а один из путей перенаправлял запросы на внешний ресурс. Тестировщик указал этот путь как redirect_uri, выполнил авторизацию тестовой учётной записью и подтвердил, что код оказался на контролируемом тестовом endpoint.
Рассматривались три варианта исправления. Проверка только домена была простой, но небезопасной; разрешение списка префиксов уменьшало число ошибок конфигурации, однако сохраняло риск открытых перенаправлений. Был выбран точный список URI для каждого клиента, дополненный обязательным PKCE для публичных клиентов.
После исправления изменённые пути, порты и поддомены стали отклоняться до выдачи кода, а штатный URI продолжил работать. Отдельно проверили, что endpoint перенаправления не допускает произвольный внешний адрес.
Нет. Даже точно разрешённый URI может принять код и затем переслать его на внешний адрес. Нужно проверять логику самого callback-обработчика: он не должен без строгого контроля перенаправлять пользователя по параметру, полученному от клиента.
Нет, PKCE в основном защищает код от использования перехватчиком, не знающим verifier. Он не предотвращает утечку кода, фишинг, ошибочную выдачу результата другому URI или атаки на клиентскую логику. Поэтому корректная регистрация и проверка redirect_uri остаются обязательными.
Только если каждый такой поддомен действительно находится под постоянным контролем организации и изоляция подтверждена. Захваченный, забытый или сторонний поддомен превращает правило доверия домену в обход проверки. Безопаснее регистрировать конкретные URI либо применять строго управляемую схему, явно учитывающую жизненный цикл поддоменов.