Waybackurls: OSINT-разведка забытых эндпоинтов

На одной из программ bug bounty я вытянул из Wayback Machine эндпоинт /api/v1/users/export?user_id= - его убрали из навигации за два года до моего захода на скоуп. Бэкенд никто не выключил. Подставил чужой числовой ID - получил полный дамп профиля, IDOR категории P2. Ни Burp Crawler, ни активный фаззинг этот маршрут не нашли: его не существовало в актуальной карте приложения. А waybackurls выдал его за три секунды.

Дальше - как собрать пайплайн пассивной разведки, который вытаскивает такие маршруты из архивов и фильтрует их под конкретные классы уязвимостей.

Зачем искать скрытые эндпоинты через Wayback Machine​

Wayback Machine хранит снапшоты веб-страниц за годы. Каждый раз, когда краулер web.archive.org обходит сайт, он фиксирует URL всех найденных страниц, API-роутов, JS-файлов и статических ресурсов. Со временем разработчики переписывают фронтенд, удаляют разделы, мигрируют API с /v1/ на /v3/. А бэкенд-роуты остаются рабочими - их убирают из навигации и документации, но не из кода.

С точки зрения MITRE ATT&CK это классический reconnaissance: поиск на сайтах жертвы (T1594) и обращение к публичным базам данных (T1596.005, Scan Databases). Ключевая разница с активным сканированием (T1595.002, Vulnerability Scanning) - нулевой контакт с целью на этапе сбора. Вы обращаетесь к архиву, не к серверу цели. Ни один WAF не зафиксирует эту активность. Для CTF-формата это вообще подарок - можно раскопать всю историю таргета, не потратив ни одного запроса к скоупу.

Русскоязычные материалы по waybackurls ограничиваются установкой и базовыми примерами: echo domain.com | waybackurls. Ни один не показывает, как из десятков тысяч архивных URL отфильтровать те, которые содержат признаки IDOR, LFI или XSS. А в этом и состоит waybackurls OSINT разведка на практике - не в сборе, а в обработке результатов.

Три причины, почему архивные URL дают преимущество перед стандартным сканированием:

• Краулер Wayback Machine видел страницы, которых нет в текущем sitemap.xml, robots.txt и кеше Google. Покрытие шире любого активного скана.
• Старые URL содержат параметры debug=, test=, admin_panel=, которые давно «удалили» из фронтенда, но не из бэкенда. Исторические параметры - золотое дно.
• Миграция с /api/v1/ на /api/v3/ не гарантирует отключение старых версий. Архив покажет все промежуточные маршруты.

По OWASP Top 10, A01:2021 Broken Access Control - ограничения доступа часто не работают как задумано. Забытый эндпоинт - это дверь, которую перестали показывать на карте здания, но замок не сменили и даже не проверили.

Установка waybackurls и базовый запуск​

waybackurls - утилита от Tom Hudson (@TomNomNom), написанная на Go. Установка: go install github.com/tomnomnom/waybackurls@latest. Бинарник появится в $GOPATH/bin/ - убедитесь, что директория добавлена в $PATH.

Базовый запуск: echo target.com | waybackurls > urls.txt. На выходе - все URL, о которых знает Wayback Machine, включая поддомены. Флаг -no-subs ограничивает сбор только основным доменом, -dates добавляет столбец с датой архивирования. На среднем домене с историей 5-7 лет выдача - от нескольких тысяч до сотен тысяч строк. Бывает, что на CTF-таргете с коротким сроком жизни выпадает всего пара десятков URL, но среди них попадается что-то забытое и вкусное.

Gau, waymore и waybackurls: сравнение инструментов разведки​

waybackurls берёт данные только из одного источника - Wayback Machine. Два инструмента расширяют охват.

gau (Get All URLs) помимо Wayback Machine запрашивает Common Crawl, AlienVault OTX и URLScan.io. Установка: go install github.com/lc/gau/v2/cmd/gau@latest. Запуск аналогичен: echo target.com | gau > gau_urls.txt.

waymore - агрегатор от xnl-h4ck3r. Объединяет все источники waybackurls и gau плюс расширенные фильтры по content-type, статус-коду и дате. Запуск: python3 waymore.py -i target.com -mode U.

На практике я запускаю waybackurls и gau параллельно, объединяя результаты:
Типичная разница: gau даёт на 15-30% больше уникальных URL за счёт дополнительных источников. Waybackurls быстрее по скорости. Waymore - самый полный, но требует Python-окружения и конфигурации API-ключей для URLScan.

Для быстрой проверки одного домена хватит waybackurls. Для полноценного сбора урлов для пентеста - связка всех трёх. На CTF, где время ограничено, я обычно запускаю waybackurls + gau и не жду waymore - скорость важнее полноты.

Фильтрация URL по паттернам: IDOR, LFI, XSS​

Из all_urls.txt с 50 000 строк вручную ничего не найти. Нужна фильтрация по паттернам, характерным для конкретных классов уязвимостей. Для этого использую grep с регулярными выражениями и gf - утилиту от TomNomNom с готовыми наборами паттернов. Установка gf: go install github.com/tomnomnom/gf@latest, затем скопируйте паттерны из репозитория 1ndianl33t/Gf-Patterns в ~/.gf/.

Поиск IDOR через архив сайта​

IDOR (Insecure Direct Object Reference) - подкласс Broken Access Control (A01:2021 OWASP). Признак в URL: числовой или предсказуемый идентификатор объекта в параметре.

Что ищу: параметры user_id=, order_id=, account=, profile=, id=, doc= с числовыми значениями, а также пути вида /users/123/, /api/v1/invoice/789.

Фильтрация: grep -iE '(user_id|order_id|account_id|profile_id|doc_id|id)=[0-9]+' all_urls.txt > idor_candidates.txt или через gf-паттерн: cat all_urls.txt | gf idor > idor_candidates.txt.

Дальше - проверка, жив ли эндпоинт: cat idor_candidates.txt | httpx -sc -cl -title -silent > idor_alive.txt. Всё, что отвечает 200 - кандидат на ручную проверку в Burp Suite: меняете ID на ID другого пользователя и смотрите, возвращает ли сервер чужие данные. Классика CTF-тасков на web - именно этот вектор.

Поиск LFI уязвимостей через старые URL​

LFI (Local File Inclusion) попадает в категорию A03:2021 Injection (OWASP). В архивных URL ищем параметры, принимающие путь к файлу: file=, path=, include=, page=, template=, dir=.

Фильтрация: cat all_urls.txt | gf lfi > lfi_candidates.txt или через grep: grep -iE '(file|path|include|page|template|dir)=' all_urls.txt > lfi_candidates.txt.

Массовая подстановка payload'а через qsreplace (установка: go install github.com/tomnomnom/qsreplace@latest): cat lfi_candidates.txt | qsreplace '../../../../etc/passwd' | httpx -sc -ms 'root:x:' -silent. Тут qsreplace заменяет значение каждого параметра на path traversal payload, а httpx фильтрует ответы, содержащие строку root:x: - признак чтения /etc/passwd.

Не каждый параметр file= ведёт к LFI. Но живой эндпоинт с пользовательским вводом без санитизации - валидная находка, и на CTF такие вещи бывают решением таска.

Поиск XSS через архивные эндпоинты​

Reflected XSS возникает там, где пользовательский ввод отражается в ответе без экранирования. Паттерны в URL: search=, q=, query=, redirect=, callback=, msg=, error=.

Фильтрация: cat all_urls.txt | gf xss > xss_candidates.txt.

Быстрая проверка: cat xss_candidates.txt | qsreplace '"><img src=x onerror=alert(1)>' | httpx -sc -ms 'onerror=alert' -silent. Если тест-строка отражается в теле ответа - высокая вероятность reflected XSS. Дальше - валидация: обход WAF, контекст инъекции (атрибут, тег, JS-блок) - ручная работа в Burp Repeater.

Полный пайплайн OSINT разведки веб-приложений для баг баунти​

. Утечка чувствительных параметров через такие файлы - отдельная категория находок, которая напрямую относится к A05:2021 Security Misconfiguration (OWASP). На одном CTF я таким способом нашёл .env с кредами от базы - таск закрылся за 4 минуты.

Разведка через waybackurls и gau создаёт ложное ощущение полноты: «собрал все URL - осталось автоматизировать». На деле большинство находок начинаются с ручной работы поверх автоматизации. Пайплайн даёт кандидатов, но подтверждение IDOR - это всегда ручная подстановка ID с двух аккаунтов и сравнение ответов. Подтверждение LFI - ручной подбор глубины path traversal под конкретную ОС и конфигурацию. Подтверждение XSS - анализ контекста вставки и обход фильтров.

Я видел десятки отчётов, где багхантер автоматически прогнал qsreplace + httpx и зарепортил отражение строки, которая находилась внутри HTML-комментария или атрибута, где она неэксплуатируема. Итог - N/A, удар по репутации на платформе. Не будьте этим парнем.

Пайплайн выше - пассивная разведка и первичный скрининг, а не эксплуатация. После скрининга начинается настоящая работа, и именно она отличает автоматизатора от багхантера с выплатами. На WAPT есть лаба именно с этим вектором + ментор в чате при затыке.