OSINT и утечки в поиске, метафайлах и страницах

OWASP Web Security Testing Guide открывает раздел 4.1 Information Gathering простой мыслью: тестировать можно только то, что удалось найти. Если robots.txt светит путь к админке, карта соответствия исходного кода (source map) отдаёт весь фронтенд в читаемом виде, а в HTML-комментарии забыт SQL-запрос с именами таблиц - поверхность атаки расширяется задолго до первого эксплойта. Разведка по открытым источникам (OSINT) в WSTG охватывает три проверки этапа сбора информации - WSTG-INFO-01, WSTG-INFO-03 и WSTG-INFO-05 - и каждая опирается на данные, которые уже опубликованы: в поисковых индексах, метафайлах и клиентском коде. Этот выпуск серии разбирает все три проверки и показывает, как отличить реальную утечку данных от публичной информации.

Разведка как фундамент аудита​

Прежде чем ковырять аутентификацию, авторизацию или бизнес-логику приложения, нужно определить scope: приложения, хосты, эндпоинты и технологии, составляющие поверхность атаки. Что не обнаружено - то не тестируется. Вне зависимости от глубины остальной проверки.

Согласно обзору Information Gathering Overview (WSTG 4.1.0), сбор информации сочетает пассивную разведку (без прямого взаимодействия с целью) и активное перечисление (с прямым взаимодействием). Современные оценки комбинируют пассивный поиск поддоменов (subfinder, Amass в пассивном режиме), проверку живых хостов (httpx), анализ Certificate Transparency, архивный сбор URL (gau, waybackurls, waymore), анализ JavaScript (jsluice, LinkFinder) и целевое обнаружение контента (ffuf, feroxbuster, Kiterunner). Конкретные примеры описаны в отдельных сценариях INFO и в главе API Reconnaissance.

Все действия должны оставаться в рамках согласованного scope - это не рекомендация, а жёсткое ограничение. Раздел 4.1 Information Gathering объединяет проверки INFO-01 - INFO-10 в единую структуру; эта статья покрывает проверки 01, 03 и 05, относящиеся к поисковой разведке, метафайлам и содержимому страниц.

Разведка через поисковые системы (WSTG-INFO-01)​

Проверка WSTG-INFO-01 описывает, как использовать поисковые системы для обнаружения утечек конфиденциальной информации. Поисковые роботы регулярно обходят миллиарды страниц, следуя по ссылкам и анализируя sitemap. Если robots.txt не обновлялся на протяжении жизни сайта и HTML-метатеги, запрещающие индексацию, не применялись - в индексе могут оказаться страницы, не предназначенные для публичного доступа.

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

Цель проверки: определить, какая чувствительная информация о проектировании и конфигурации приложения, системы или организации доступна напрямую (на сайте организации) или косвенно (через сторонние сервисы).

Что искать: сетевые диаграммы и конфигурации; архивные посты и письма администраторов; процедуры входа и форматы имён пользователей; учётные данные и приватные ключи; конфигурации облачных сервисов; содержимое сообщений об ошибках; непубличные версии приложений (dev, test, UAT, staging).

Какие поисковые системы использовать. WSTG рекомендует не ограничиваться одним поисковиком - результаты различаются в зависимости от времени последнего обхода и алгоритма ранжирования. Среди рекомендуемых: Baidu, Bing (поддерживает расширенные ключевые слова), binsearch.info (бинарные Usenet-группы), Common Crawl (открытый репозиторий данных обхода), DuckDuckGo (конфиденциальность, собственный синтаксис поиска), Google (поддерживает поисковые операторы), Internet Archive Wayback Machine. Отдельно стоят специализированные сервисы: Censys индексирует интернет-инфраструктуру (серверы, сертификаты, открытые сервисы) и предлагает бесплатный community-тариф; Shodan ищет подключённые к интернету устройства и сервисы.

Поисковые операторы и Google dorking утечки данных​

Поисковый оператор (search operator) - специальное ключевое слово или синтаксическая конструкция, расширяющая возможности обычного запроса. Основные операторы:

• site: - ограничить результаты указанным доменом. Согласно документации Google, оператор site: не гарантирует возврат всех проиндексированных URL в указанном префиксе.
• inurl: - результаты только с ключевым словом в URL.
• intitle: - результаты только с ключевым словом в заголовке страницы.
• intext: / inbody: - поиск ключевого слова только в теле страниц.
• filetype: - совпадение только с определённым типом файла (.pdf, .php и др.).

Интерфейс Google Advanced Search предоставляет выбор расположения ключевых слов - в заголовке, тексте, URL или ссылках на страницу - как альтернативу ручному синтаксису операторов.

Google Hacking (Dorking) - комбинирование операторов для обнаружения конкретных типов файлов и конфиденциальной информации. Техника применима не только к Google, но и к другим поисковикам, поддерживающим операторы. Google Hacking Database содержит категории дорков: Footholds, Files containing usernames, Sensitive Directories, Web Server Detection, Vulnerable Files, Vulnerable Servers, Error Messages, Files containing juicy info, Files containing passwords, Sensitive Online Shopping Info. AI-ассистенты вроде DorkGPT переводят описание на естественном языке в синтаксис дорков, сокращая ручные усилия.

Архивы, кэши и автоматический сбор URL​

Internet Archive Wayback Machine - самый полный инструмент для просмотра исторических снимков веб-страниц, хранящий архив с 1996 года. Для просмотра архивных версий сайта используется URL вида https://web.archive.org/web/*/owasp.org, который отображает календарь со всеми доступными снимками. API Wayback Machine возвращает единственный ближайший снимок с меткой времени и статусом для запрошенного URL.

Тут важно не перепутать: время снимка и текущая доступность - разные вещи. Архивная копия подтверждает, что содержимое было доступно на момент захвата, но не доказывает текущую утечку. Чтобы подтвердить экспозицию, нужно запросить обнаруженный путь на живом сайте.

Другие сервисы кэшированного контента: archive.ph (он же archive.md) - создаёт постоянные снимки по запросу; CachedView - агрегирует кэшированные страницы из нескольких источников, включая исторические данные Google Cache и Wayback Machine. Оператор cache: в Google Search больше не работает - его документация удалена, поскольку функция прекратила работу.

Автоматизированный сбор URL из архивов часто раскрывает забытые эндпоинты, старые пути API, резервные файлы и параметры, более не связанные с живым приложением:

• gau - агрегирует URL из AlienVault OTX, Wayback Machine и Common Crawl.
• waybackurls - извлекает URL, известные Wayback Machine для домена.
• waymore - расширяет покрытие за счёт Wayback Machine, Common Crawl, AlienVault OTX, URLScan и VirusTotal; может также извлекать исторические ответы.

Утилита unfurl полезна для извлечения компонентов (ключей, путей, доменов) из больших списков URL. Итоговый список фильтруется по расширениям, параметрам или статус-кодам и передаётся сканерам. Обнаруженные хосты и пути проверяются на принадлежность scope.

Инструменты OSINT для разведки и корреляции​

Помимо отдельных поисковиков, для корреляции и визуализации связей между обнаруженными сущностями применяются специализированные OSINT-фреймворки.

Maltego - платформа анализа связей, отображающая отношения между доменами, IP-адресами, email-адресами и организациями через автоматизированные трансформы. Начинаешь с одной сущности - домена или email - и через пару минут видишь связанную инфраструктуру на графе. Доступна бесплатная Community Edition для некоммерческого использования.

Другие инструменты OSINT-разведки: theHarvester (сбор email-адресов, поддоменов и имён), Amass в пассивном режиме (глубокое картирование поверхности атаки), subfinder (быстрое пассивное перечисление поддоменов).

Утечки в метафайлах веб-сервера (WSTG-INFO-03)​

Проверка WSTG-INFO-03 описывает тестирование метаданных (metadata) - файлов, раскрывающих пути, функциональность и техническую информацию веб-приложения. Список директорий, запрещённых для роботов, может использоваться как зависимость для построения карты путей выполнения приложения. Собранная информация также полезна для определения поверхности атаки, технологического стека или применения в социальной инженерии.

Цели проверки: обнаружить скрытые или замаскированные пути и функциональность через анализ метафайлов; извлечь информацию для лучшего понимания систем.

Как тестировать: все описанные действия выполняются через wget или curl. DAST-инструменты (ZAP, Burp Suite) включают проверки и парсинг этих ресурсов в составе паука/краулера. Метафайлы также обнаруживаются через Google Dorks или расширенный поиск с оператором inurl:.

robots.txt, AI-краулеры и анализ метаданных​

robots.txt определяется Robots Exclusion Protocol (RFC 9309). Файл размещается в корневой директории веб-сервера, содержит директивы User-Agent, Disallow и Allow. Синтаксис формален: группы правил, специальные символы #, $, *; файл должен располагаться по пути /robots.txt, кодировка UTF-8, MIME-тип text/plain.

И вот здесь классическая ловушка: robots.txt - это не механизм контроля доступа. RFC 9309 прямо указывает, что протокол исключения роботов не заменяет реальные меры безопасности контента - перечисление путей в robots.txt делает их публично обнаруживаемыми. Роботы могут намеренно игнорировать директивы Disallow. По сути, robots.txt - это вежливая просьба, а не забор.

Учебный пример 1. Условный локальный сайт содержит robots.txt с путём /internal-notes и синтетический комментарий в HTML. Действия: извлечь путь из robots.txt, запросить /internal-notes как неаутентифицированный пользователь, сравнить содержимое с документированным публичным разделом. Если содержимое доступно гостю и не является публичным - подтверждена экспозиция закрытой заметки; запись в robots.txt объясняет только обнаружение пути, но не является причиной утечки. Отрицательный контроль: если путь возвращает 403 Forbidden - доступа к содержимому нет, и это не утечка данных. Наличие пути в robots.txt без доступа к содержимому - информация об архитектуре, а не нарушение конфиденциальности.

AI-краулеры. Многие AI-краулеры, используемые для сбора обучающих данных, игнорируют директивы robots.txt. Открытое сообщество отвечает тактиками: генерация бесконечного фейкового контента для расходования ресурсов краулера или отдача искажённых данных. Согласно документации OpenAI, определены независимые директивы opt-out для OAI-SearchBot, GPTBot, OAI-AdsBot и ChatGPT-User. При этом ChatGPT-User используется для действий, инициированных пользователем, - в этом случае правила robots.txt могут не применяться. Для тестирования это означает: записи robots.txt, предназначенные для блокировки AI-краулеров (например, User-Agent: GPTBot), могут оказаться неэффективными, а чувствительные пути в robots.txt остаются обнаруживаемыми.

Анализ robots.txt через Google Webmaster Tools. Владельцы сайтов могут использовать функцию «Analyze robots.txt» в Google Webmaster Tools: войти с аккаунтом Google, ввести URL сайта на панели управления, выбрать метод анализа.

Robots META-тег. Тег <META NAME="ROBOTS"> размещается в секции <HEAD> HTML-документа. Если тег отсутствует, протокол по умолчанию применяет INDEX,FOLLOW. Директивы NOINDEX и NOFOLLOW запрещают индексацию и переход по ссылкам. При аудите выполняется поиск <META NAME="ROBOTS" по каждой странице; результат сравнивается с директивами robots.txt в корне сайта.

Информационные META-теги. Организации встраивают META-теги для поддержки экранных читалок, превью в социальных сетях и поисковой индексации. Для аудитора интересны: <meta name="description">, <link rel="canonical">, Open Graph теги (og:title, og:url, og:image), Twitter Card теги (twitter:card, twitter:site), а также <meta property="article:publisher"> и article:modified_time. Эти данные помогают определить используемые технологии и обнаружить дополнительные пути.

Sitemap, security.txt, humans.txt и .well-known​

Sitemaps. Файл sitemap.xml предоставляет информацию о страницах, видео и других ресурсах сайта и их взаимосвязях. Согласно спецификации sitemaps.org, файл sitemap ограничен по scope: sitemap, расположенный по адресу http://example.com/catalog/sitemap.xml, может включать только URL, начинающиеся с http://example.com/catalog/, но не с http://example.com/images/. Для аудитора sitemap - источник обнаружения разделов, не связанных из основной навигации.

security.txt ратифицирован IETF как RFC 9116. Файл позволяет сайтам определять политики безопасности и контактные данные. Расположение: /security.txt или /.well-known/security.txt. Согласно RFC 9116, поле Contact обязательно - указывает метод связи для сообщений об уязвимостях (email, телефон, веб-страница). Поле Expires тоже обязательно. Файл security.txt зарегистрирован как постоянная запись в реестре IANA well-known URI.

Оговорка из RFC 9116: наличие или отсутствие security.txt не даёт и не запрещает разрешение на тестирование безопасности. Для аудитора файл полезен при обнаружении дополнительных путей, OSINT-сборе, получении информации о bug bounty и социальной инженерии. Ссылки на OpenPGP-ключи в security.txt могут содержать метаданные: Key ID, Key Fingerprint, алгоритм, размер ключа, дату создания и истечения, User IDs с именем и email владельца.

humans.txt - инициатива для указания людей за сайтом. Файл часто содержит информацию о вакансиях и карьерных путях.

Другие .well-known ресурсы. RFC и интернет-черновики определяют стандартные файлы в директории .well-known/. Списки доступны в реестре IANA и на Wikipedia. При тестировании составляется список из RFC/черновиков для проверки существования или содержимого таких файлов краулером или фаззером.

Инструменты для проверки метафайлов: браузер (View Source, DevTools), curl, wget, Burp Suite, ZAP.

Утечки данных на веб-страницах (WSTG-INFO-05)​

Проверка WSTG-INFO-05 охватывает утечки информации через комментарии HTML, метаданные, клиентский JavaScript, source maps, тела редиректов и метаданные сгенерированных документов. Разработчики нередко оставляют в HTML-коде отладочные комментарии, а во фронтенд-коде - захардкоженные API-ключи, внутренние IP-адреса, маршруты к скрытым страницам и даже учётные данные.

Цели проверки: обнаружить утечки в комментариях, метаданных и телах редиректов; собрать JavaScript-файлы и проанализировать код; установить наличие source maps и отладочных файлов.

HTML-комментарии и метаданные документов​

HTML-комментарии (<!-- ... -->) используются разработчиками для отладки и нередко попадают в продакшен. Аудитор ищет в исходном коде комментарии, содержащие SQL-запросы, имена пользователей, пароли, внутренние IP-адреса или отладочную информацию. Пример условного комментария: <!-- Query: SELECT id, name FROM app.users WHERE active='1' --> - раскрывает структуру таблицы и активный запрос.

Информация о версии HTML (DOCTYPE и DTD URL) помогает профилировать приложение. META-теги - Author, Refresh (перенаправление через заданный интервал), keywords - не создают прямого вектора атаки, но позволяют собирать данные о приложении. Стандарты PICS (Platform for Internet Content Selection) и POWDER (Protocol for Web Description Resources) предоставляют инфраструктуру для ассоциации метаданных с интернет-контентом.

JavaScript, source maps и анализ клиентского кода​

Разработчики часто хардкодят чувствительную информацию в JavaScript-переменных на фронтенде. Проверяется исходный код между тегами <script> и внешние .js-файлы. Среди утечек: API-ключи (например, нерестрикт Google Maps API Key), строки подключения к базам данных, внутренние IP-адреса, маршруты к скрытым административным страницам, конфигурации staging-окружений.

При обнаружении API-ключа проверяется, настроены ли ограничения по сервису, IP, HTTP referrer или приложению. Если ключ Google Maps ограничен только определёнными API, атакующий может использовать его для запросов к нерестрикт API за счёт владельца. Ключ вроде бы «ограничен» - а счёт всё равно растёт.

Анализ клиентского кода. Современные SPA и тяжёлый клиентский код часто содержат API-эндпоинты, feature flags и секреты. После сбора JavaScript-файлов (вручную, через прокси или с помощью инструментов) данные извлекаются с помощью jsluice urls bundle.js и jsluice secrets bundle.js, а также python linkfinder.py -i bundle.js -o cli. Результаты сопоставляются с архивным сбором URL (gau / waybackurls / waymore) и техниками из проверок Identify Application Entry Points и API Reconnaissance.

Source maps. Карта соответствия исходного кода - специальный файл, связывающий минифицированную версию ассета (CSS или JavaScript) с исходной авторской версией. Согласно документации Chrome DevTools, source maps позволяют загрузить и отладить оригинальные файлы исходного кода, соответствующие минифицированному развёрнутому коду, - браузер выполняет минифицированный код, но панель Sources показывает авторский исходник. Файлы source map обычно загружаются при открытии DevTools. Аудитор может обнаружить их, добавив расширение .map к пути JS-файла: например, если виден /static/js/main.chunk.js, проверяется /static/js/main.chunk.js.map.

Учебный пример 2. Условный учебный бандл содержит комментарий //# sourceMappingURL=main.chunk.js.map и соответствующий JSON-файл source map:
Действия: обнаружить source map, найти в массиве sources абсолютные пути серверной файловой системы и фиктивный тестовый токен в восстановленном исходном коде, сверить его назначение в стенде. Ожидаемый результат: описана экспозиция исходного кода (имя пользователя sysadmin, структура каталогов, названия модулей - cashoutAction, userAction); установлен реальный эффект тестового секрета (действующий или уже ротированный). Отрицательный контроль: публичный идентификатор клиента (client ID, не являющийся секретом) или ссылка на уже несуществующий архивный файл не квалифицируется как действующий секрет. Различие между экспозицией исходного кода и утечкой действующего секрета - ключевой элемент отчёта.

Перенаправления и метаданные сгенерированных файлов​

Тело 3xx-ответов. Ответы перенаправления (серия 300) обычно не содержат значимого контента - но никто не гарантирует их пустоту. Типичная ситуация: проверка аутентификации или авторизации проваливается, сервер отвечает редиректом на «безопасную» страницу - но тело самого редиректа содержит контент, не отображаемый браузером, однако передаваемый клиенту. Браузер послушно переходит по Location, а в теле ответа валяется то, что видеть не надо. Обнаружить это можно через DevTools браузера или через прокси (ZAP, Burp, Fiddler, Charles).

Метаданные сгенерированных документов. Веб-приложения генерируют скачиваемые файлы: PDF, электронные таблицы, отчёты. Они могут содержать встроенные метаданные, описывающие ПО или библиотеки, использованные для создания. Поля Producer, Creator, Application, Library Version раскрывают бэкенд-технологии и конкретные версии - эта информация помогает атакующему определить публично известные уязвимости (CVE). Условный пример: поле Producer: iText 2.1.7 в сгенерированном PDF позволяет искать известные уязвимости этой версии.

Проверка выполняется загрузкой файлов из приложения и инспекцией метаданных: exiftool file.pdf, pdfinfo file.pdf, strings file.pdf | grep -i producer для PDF; exiftool file.docx для Office-документов. Проверяются поля Producer, Creator, Application, Creation Tool, Library Version.

Корреляция находок​

Обнаруженные данные из разных источников (поисковые индексы, архивы, метафайлы, клиентский код, метаданные документов) требуют корреляции. Для каждой находки фиксируется:

• Владелец - кому принадлежит ресурс (домен, IP-адрес, email).
• Источник - где обнаружена информация (поисковый индекс, Wayback Machine, robots.txt, source map, HTML-комментарий).
• Дата - время обнаружения; для архивных данных - дата снимка. Архивные и текущие наблюдения подписываются раздельно.
• Текущий endpoint - доступен ли ресурс на момент аудита. Историческая копия из Wayback Machine не эквивалентна текущей утечке.
• Чувствительность - содержит ли находка реальный секрет (действующий токен, пароль) или публичную информацию (client ID, версия библиотеки).

Минимально необходимое доказательство: подтверждение доступности ресурса гостем (неаутентифицированным пользователем) на живом сайте и демонстрация, что содержимое не является документированной публичной информацией. Полный действующий секрет (токен, пароль) никогда не включается в отчёт в открытом виде - достаточно указать тип, местоположение и подтвердить действительность.

Исправления и работа с индексом​

WSTG-INFO-01 формулирует ключевой принцип: тщательно оценивать чувствительность информации о проектировании и конфигурации перед её публикацией и периодически пересматривать чувствительность уже опубликованных данных.

На практике исправления охватывают три области:

1. Закрытие исходного доступа. Убрать чувствительный контент из публичного доступа: удалить или обновить содержимое, закрыть паролем, добавить тег noindex, настроить корректные правила авторизации. Записи в robots.txt сами по себе не закрывают доступ - они лишь просят роботов не индексировать пути.
2. Ротация раскрытых секретов. Если обнаружен действующий API-ключ, пароль или токен - его замена обязательна вне зависимости от закрытия доступа. Удаление файла с секретом без ротации бесполезно: ключ уже мог быть скопирован.
3. Работа с поисковым индексом. Удаление контента с сайта не удаляет его из кэша поисковиков. Инструмент Google Removals обеспечивает временное подавление (около 6 месяцев). Для постоянного удаления из результатов Google Search необходимо удалить или обновить контент, закрыть страницу паролем или добавить метатег noindex. Чувствительные файлы и source maps исключаются из публичной сборки - через конфигурацию webpack, исключение .map-файлов из деплоя и проверку на уровне CI/CD.

Инструменты для описанных проверок (сводный список из INFO-03 и INFO-05): wget, curl, браузер (View Source, DevTools), ZAP, Burp Suite, gau, waybackurls, waymore, LinkFinder, xnLinkFinder, jsluice, SecretFinder, Google Maps API Scanner, exiftool.

Справочные ресурсы из WSTG-INFO-05: KeyHacks (коллекция способов проверки обнаруженных API-ключей), RingZer0 Online CTF - Challenge 104 «Admin Panel». Нормативные документы: спецификация HTML version 4.01, XHTML, WHATWG HTML Living Standard.



Подход к OSINT утечкам данных, описанный здесь, выглядит простым - открыть robots.txt, проверить source maps, прогнать домен через архивы. Но повторяющаяся ошибка аудиторов не в незнании инструментов, а в неумении отличить находку от утечки. Обнаружить путь /admin-backup в robots.txt - это не утечка, а информация об архитектуре. Обнаружить доступный без аутентификации дамп базы по этому пути - утечка. Обнаружить API-ключ в source map - экспозиция, но если ключ ограничен по referrer и не может быть использован за пределами легитимного домена - это не действующий секрет.

Чёткое разграничение между «это видно» и «это эксплуатируемо» определяет качество отчёта. Тот же принцип работает и в обратную сторону: не стоит заявлять текущую утечку по старому снимку Wayback Machine, сделанному три года назад. Без подтверждения доступности на живом сервере архивная копия - исторический артефакт, и формулировка «обнаружена утечка» по ней будет ошибочной. Факт-чекинг собственных находок до включения в отчёт - базовая гигиена аудитора.



Источники и атрибуция

Основа статьи - OWASP Web Security Testing Guide (WSTG), OWASP Foundation и авторы соответствующих разделов. Использованные материалы (снимки от 2026-11-01):

• 4.1 Information Gathering - структурный индекс раздела.
• 4.1.0 Information Gathering Overview - обзор этапа сбора информации.
• WSTG-INFO-01: Conduct Search Engine Reconnaissance for Information Leakage - разведка через поисковые системы.
• WSTG-INFO-03: Review Webserver Metafiles for Information Leakage - анализ метафайлов.
• WSTG-INFO-05: Review Web Page Content for Information Leakage - анализ содержимого страниц.

Нормативные спецификации: RFC 9309 (Robots Exclusion Protocol), RFC 9116 (security.txt), протокол Sitemaps, реестр IANA well-known URI.

Русский перевод и редакционная актуализация - Codeby. Изменения относительно оригинала: объединение трёх проверок (INFO-01, INFO-03, INFO-05) и вводного обзора (4.1.0) в единый материал; добавление учебных примеров с отрицательным контролем; уточнения на основе текущей документации Google (прекращение работы оператора cache:, ограничения инструмента Removals), документации OpenAI (директивы AI-краулеров) и RFC 9309/9116; адаптация для русскоязычной аудитории.

Лицензия перевода и адаптации: CC BY-SA 4.0.

Вся серия WSTG · Предыдущая статья