Статья robots.txt, sitemap и .well-known: пассивная разведка веб-инфраструктуры без единого скана

На pre-engagement фазе аудита одного финтех-сервиса я отправил ровно один GET-запрос - к /robots.txt. В ответ получил пути к staging-среде с открытым Swagger UI, два административных эндпоинта и структуру внутреннего API. Ноль записей в IDS заказчика, ноль алертов в WAF, ноль подозрений у SOC - потому что запрос к текстовому файлу неотличим от визита Googlebot. По данным Verizon DBIR 2025, 26% подтверждённых нарушений связаны с веб-атаками, и большинство начинаются с разведки, которую невозможно поймать штатными средствами мониторинга. Три публичных файла - robots.txt, sitemap.xml и директория .well-known - превращают footprinting веб-сайта в тривиальную задачу, а для Blue Team остаются слепой зоной по определению.

Control files в цепочке атаки: footprinting до первого скана​

Анализ control files укладывается в тактику Reconnaissance по MITRE ATT&CK - техника Search Open Websites/Domains (T1593). Атакующий вытягивает данные об архитектуре приложения из публично доступных файлов без прямого взаимодействия с защищаемой инфраструктурой.

Что до. Определение scope: выбор домена, согласование правил engagement. Control files - первое действие после выбора цели, ещё до DNS-разведки и CT-логов.

Что после. Обнаруженные пути - /admin, /api/v2/internal, /staging - ложатся в список для активной разведки: fingerprinting сервисов, directory fuzzing, проба аутентификации. Каждый путь из robots.txt - гипотеза, которую проверяют через прямое обращение. Качественная пассивная фаза сокращает количество шумных запросов на следующем этапе. Меньше шума - меньше шанс, что SOC проснётся.

Почему Blue Team не видит этот этап. Запрос к /robots.txt или /sitemap.xml - штатная HTTP-операция. Googlebot, Bingbot, SEO-краулеры делают это десятки тысяч раз в сутки. Ни один WAF и ни один IDS не выдаст алерт на такой трафик. В Sigma-правилах для T1593 описаны детекции подозрительного клонирования Git-репозиториев (proc_creation_lnx_susp_git_clone.yml, proc_creation_win_git_susp_clone.yml), но простой GET к control file - слепая зона для любого стека мониторинга. Единственная стратегия - минимизировать то, что эти файлы отдают наружу.

[Применимо: внешний пентест, black box, pre-engagement OSINT]

По классификации OWASP - это A05:2021, Security Misconfiguration: неполная или небезопасная конфигурация, которая раскрывает внутреннюю архитектуру.

robots.txt и утечка информации: что атакующий читает за 30 секунд​

Файл robots.txt задуман как подсказка для поисковых краулеров - какие разделы не индексировать. На практике каждая директива Disallow - прямое указание на путь, который владелец сайта хотел спрятать. Атакующий читает этот файл не как инструкцию куда не ходить, а как перечень самого интересного.

Паттерны, которые раскрывают архитектуру​

Вот что я регулярно нахожу на реальных проектах:

• Disallow: /admin, /panel, /dashboard - административные интерфейсы. Атакующий сразу понимает: здесь стоит попробовать brute-force или проверить дефолтные креды
• Disallow: /api/v2/internal, /api/debug - внутренние API-эндпоинты, часто без аутентификации на staging
• Disallow: /staging, /dev, /test - окружения разработки. По данным CrowdStrike Global Threat Report 2025, 75% вторжений используют валидные учётные данные, а staging-среды часто работают с тестовыми аккаунтами и паролями по умолчанию
• Disallow: /backup, /dump, /export - резервные копии и дампы данных
• Disallow: /wp-admin, /wp-includes - мгновенный fingerprint CMS (WordPress), после которого атакующий ищет известные уязвимости конкретной версии

Отдельный класс - чрезмерно детальный robots.txt. Когда файл содержит 30-50 директив, он рисует полную карту маршрутизации приложения: раздел кабинета, раздел API, админка, система отчётов, middleware-пути. По сути, разработчик сам нарисовал карту для атакующего.

Историческая разведка через Wayback Machine​

Текущий robots.txt - половина картины. Через Wayback Machine (web.archive.org) атакующий получает историю изменений файла за годы. Путь, удалённый из robots.txt в прошлом году, может до сих пор работать на сервере - его убрали из файла, но не отключили. Один вызов curl -s "https://web.archive.org/web/2023*/https://target.com/robots.txt" покажет все сохранённые версии, а diff между ними выявит исчезнувшие пути, которые стоит проверить.

Практический пример​

# Получить robots.txt и отфильтровать пути
curl -s https://target.com/robots.txt | grep -i 'disallow' | awk '{print $2}' | sort -u

Эта команда за секунду выдаёт список всех запрещённых путей. На типичном корпоративном сайте я получаю от 5 до 40 уникальных путей - каждый из них потенциальная точка входа.

Когда техника НЕ работает. Пустой robots.txt (только User-agent: * и Allow: /) не раскрывает ничего. Сайты за CDN (Cloudflare, Akamai) могут отдавать генерический robots.txt от CDN, а не от приложения. Маленькие лендинги и SPA без серверного рендеринга часто не имеют robots.txt вообще.

sitemap.xml - разведка по индексу забытых страниц​

Файл sitemap.xml создаётся для поисковых систем - чтобы те проиндексировали все страницы сайта. Для атакующего это готовый каталог URL, включая те, о которых команда разработки давно забыла.

Что сайтмапы раскрывают непреднамеренно​

• Структура URL -> архитектура маршрутизации: /users/{id}/settings, /api/v1/reports/{type} - атакующий видит формат параметров и предсказывает IDOR-вектора
• Метки времени <lastmod> -> хронология активности: какие разделы обновлялись недавно, а какие заброшены. Заброшенные - значит менее патченные
• Legacy-пути -> страницы /beta, /old-dashboard, /v1-deprecated, которые не убрали из sitemap после миграции. Они часто крутятся на устаревших фреймворках
• Языковые версии -> hreflang-атрибуты раскрывают локали и поддомены для разных регионов - расширяют карту поверхности атаки
• Документация API -> пути к Swagger UI, Redoc или OpenAPI-спецификациям иногда попадают в sitemap через автоматическую генерацию CMS

Sitemap index - вложенные карты​

Крупные сайты используют sitemap-index.xml, который ссылается на десятки дочерних карт: sitemap-products.xml, sitemap-blog.xml, sitemap-internal.xml. Само имя файла внутри индекса уже указывает на структуру приложения. Дочерние карты с именами вроде sitemap-api.xml или sitemap-admin.xml - прямая наводка.

Для извлечения всех URL из sitemap достаточно curl -s https://target.com/sitemap.xml | grep -oP '<loc>\K[^<]+'. Если в ответе XML с тегами <sitemap> вместо <url> - это индексный файл, и нужно рекурсивно пройтись по каждой вложенной карте.

Когда техника НЕ работает. SPA-приложения на React/Vue без server-side rendering редко имеют sitemap. Сайты, полностью закрытые авторизацией (банк-клиенты, B2B-порталы), не публикуют карту. Динамически сгенерированные sitemap из CMS (WordPress, Django) могут содержать только актуальные страницы без legacy-хвостов.

.well-known endpoint - разведка через стандартизированные пути​

Директория /.well-known/ определена в RFC 8615 как стандартизированное место для метаданных сайта. В отличие от robots.txt и sitemap, здесь лежат файлы, описывающие инфраструктуру аутентификации, политики безопасности и связи с мобильными приложениями. Многие разработчики настраивают .well-known-эндпоинты "по инструкции" и больше никогда не проверяют, что именно они отдают наружу.

security.txt (RFC 9116)​

Файл /.well-known/security.txt содержит контактные данные для ответственного раскрытия уязвимостей. Что из него вытягивает атакующий:

• Contact - email или URL ответственного за безопасность. Адрес вида security@corp.com подтверждает домен, раскрывает формат корпоративных email и даёт точку входа для целевого фишинга
• Acknowledgments - URL страницы благодарностей исследователям. Перечень прошлых находок косвенно указывает на типы уязвимостей, которые были в продукте
• Policy - ссылка на программу Bug Bounty или VDP. Указывает scope разрешённого тестирования и перечисляет активы
• Encryption - PGP-ключ. Сам по себе не опасен, но metadata ключа (email UID, дата создания) добавляет данные в профиль организации

openid-configuration​

Эндпоинт /.well-known/openid-configuration - стандарт OpenID Connect Discovery. Возвращает JSON с полной топологией аутентификации:

• issuer - URL провайдера идентификации (Keycloak, Auth0, Azure AD, собственный сервер)
• authorization_endpoint, token_endpoint - конкретные пути для OAuth-потоков
• jwks_uri - адрес публичных ключей подписи токенов
• scopes_supported - список scope'ов приложения (может раскрыть наличие внутренних API-scope'ов)

Для Blue Team это один из самых недооценённых exposure-векторов. Атакующий получает полную схему аутентификации без единого подозрительного запроса. Зная issue и endpoint'ы, он может целенаправленно искать уязвимости в конкретной версии identity provider.

Другие .well-known эндпоинты​

• apple-app-site-association - JSON для Universal Links на iOS. Раскрывает bundle ID мобильного приложения и пути, которые оно обрабатывает
• assetlinks.json - аналог для Android App Links. Содержит SHA-256 фингерпринт сертификата приложения и package name
• change-password - стандартизированный редирект на страницу смены пароля. Подтверждает наличие учётных записей и раскрывает архитектуру auth-модуля

Когда техника НЕ работает. Не все сайты реализуют .well-known. Security.txt, несмотря на RFC-статус, встречается далеко не везде. openid-configuration отсутствует, если сайт не использует OIDC. Для маленьких проектов директория обычно пуста.

Workflow passive recon: от трёх файлов к карте инфраструктуры​

Максимальную ценность control files дают при корреляции данных из всех трёх источников. Ниже - workflow, который я гоняю на каждом проекте.

Требования к окружению​

• Любая ОС с установленным curl (GNU/Linux, macOS, WSL на Windows)
• Опционально: jq для парсинга JSON из .well-known, xmllint для sitemap
• Интернет-соединение (все запросы идут к целевому домену - штатные HTTP-запросы)
• RAM и CPU - без ограничений, нагрузка минимальна

Три шага​

Шаг 1. Сбор. Последовательно запрашиваю robots.txt, sitemap.xml (и все дочерние карты из индекса), /.well-known/security.txt, /.well-known/openid-configuration. Каждый ответ сохраняю в файл с меткой даты.

Шаг 2. Парсинг. Из robots.txt извлекаю все Disallow-пути. Из sitemap - все <loc> URL. Из openid-configuration - issuer, все endpoint-URL. Из security.txt - контакты и ссылки. Объединяю уникальные пути в единый список.

Шаг 3. Корреляция. Сравниваю находки:

• Путь есть в robots.txt Disallow, но отсутствует в sitemap -> вероятно, активный скрытый эндпоинт
• Путь есть в sitemap, но давно не обновлялся (lastmod старше года) -> legacy, приоритет на проверку
• openid-configuration указывает на отдельный поддомен (auth.target.com) -> расширение scope разведки через CT-логи и passive DNS для этого поддомена

Именно на третьем шаге начинается самое интересное. Один раз на проекте корреляция показала, что путь /api/v1/internal был в robots.txt, но не в sitemap - и по этому пути висел незащищённый GraphQL Playground.

Trade-off таблица: что даёт каждый источник​

Источник	Что раскрывает	Надёжность данных	Частота наличия
robots.txt	Скрытые пути, admin-панели, CMS-тип	Высокая - автор явно перечислил	Высокая (80%+ сайтов)
sitemap.xml	Полная карта URL, timeline, legacy-пути	Средняя - может быть неактуальным	Средняя (50-70%)
.well-known	Auth-инфраструктура, контакты, app-связи	Высокая - стандартизированный формат	Низкая (20-40%)

Результат корреляции - карта, которая ложится в основу активной фазы. Без неё пентестер начинает слепой directory brute-force, генерирует тысячи запросов и оставляет следы в логах. С ней - точечные проверки десятка конкретных путей.

External attack surface management: чеклист аудита control files​

Ниже - нумерованный чеклист, пригодный для передачи сисадмину или включения в отчёт по аудиту. Каждый пункт - конкретное действие.

📚 Часть контента скрыта. Этот материал доступен участникам сообщества с рангом One Level или выше
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме

Зарегистрироваться или Войти

Каждые полгода стоит проходить по этому чеклисту заново - при каждом мажорном релизе control files могут измениться, и новые пути утекают в robots.txt незаметно для SOC.

Большинство специалистов по защите воспринимают robots.txt как SEO-артефакт, не имеющий отношения к безопасности. Это ошибка, которая стоит дорого. Директива Disallow: /admin-panel-v3 - не защита, а приглашение. Атакующий получает конкретный путь без единого скана, без единого алерта, без единого лога. Security through obscurity критикуется десятилетиями, но в 2025 году сотни организаций продолжают "прятать" критичные эндпоинты в текстовом файле, доступном любому curl-запросу. На моей практике аудита веб-инфраструктуры восемь из десяти проектов имеют избыточный robots.txt, раскрывающий то, что должно быть закрыто аутентификацией или сетевой сегментацией. И самое неприятное: даже после аудита и очистки файла - его старые версии навсегда сохранены в Wayback Machine. Проблема не в том, чтобы "почистить" robots.txt. Проблема в том, чтобы перестать считать его инструментом безопасности и строить защиту на уровне доступа. Если в команде обсуждаете, как именно выстроить процесс аудита внешней поверхности - на codeby.net есть тред, где разбираем конфигурацию EASM и мониторинг control files на практике.