Карта архитектуры, поверхности атаки и точек входа

Три IP-адреса и два доменных имени с пометкой «проверить веб-приложения». Типичное задание на оценку. Запускаешь полное сканирование 65535 портов по одному из адресов - и вместо ожидаемого Apache на 80-м порту получаешь восемь HTTP-сервисов: Apache, административный интерфейс Samba SWAT на 901, MX4J на 8000 и Tomcat на 8080. У каждого своя поверхность атаки (attack surface), и ни один не указан в исходном задании. Эта статья объединяет три проверки OWASP WSTG - идентификацию поверхности атаки (WSTG-INFO-04), определение точек входа (entry point) (WSTG-INFO-06) и картирование архитектуры (WSTG-INFO-10) - в единый рабочий процесс: от перечня доменов к карте приложений с входами и границами доверия.

Реестр scope и оценка поверхности атаки​

Идентификация поверхности атаки веб-приложения - это обнаружение всех приложений, доменов, виртуальных хостов и внешне доступных сервисов целевой инфраструктуры. Процесс выходит за рамки очевидных точек: DNS-перечисление, обнаружение поддоменов, анализ виртуальных хостов (virtual host), сканирование нестандартных портов, разбор цифровых сертификатов и логов прозрачности сертификатов (Certificate Transparency). С распространением виртуального хостинга и разделяемой инфраструктуры связь 1:1 между IP-адресом и веб-сервером практически исчезла. Один адрес может обслуживать приложения из разных доменов, сред и административных интерфейсов. Пропустишь хотя бы один актив - получишь неполную оценку и дыру в отчёте.

Цели проверки WSTG-INFO-04: перечислить все веб-приложения в рамках scope; определить DNS-имена, домены и виртуальные хосты цели; обнаружить дополнительные домены и поддомены пассивными и активными методами; проанализировать цифровые сертификаты и логи CT на предмет дополнительных имён хостов.

Инфраструктура в задании указывается как набор IP-адресов, блок сетевых адресов, список DNS-имён или их комбинация. Если правила проведения не ограничивают scope конкретным URL, проверка стремится к максимальному охвату. Три фактора определяют, сколько приложений связано с одним именем или адресом.

Приложения на нестандартных URL​

Приложение не обязано жить в корне сайта. За одним доменом могут работать несколько систем: https://www.example.com/app1, https://www.example.com/app2, https://www.example.com/app3. Обращение к корню вернёт пустую страницу, а приложения останутся скрытыми без знания конкретных путей. Иногда это ошибка конфигурации, иногда - осознанное решение: неафишируемый административный интерфейс, до которого «никто не доберётся».

Полностью установить наличие таких приложений невозможно. Но есть несколько подходов: проверить листинг каталогов (при ошибочной конфигурации сервера); использовать поисковые системы с оператором site:www.example.com для поиска проиндексированных URL; применить словарный перебор вероятных путей (/webmail, /admin, /portal) через ffuf, feroxbuster или gobuster. Сканеры уязвимостей тоже способны обнаружить подобные интерфейсы.

Обнаружение через нестандартные порты​

Веб-приложения стандартно работают на портах 80 (HTTP) и 443 (HTTPS), но могут использовать произвольный TCP-порт. Nmap с ключом -sV определяет сервисы: nmap -Pn -sT -sV -p0-65535 192.168.1.100. В условном результате на одном адресе обнаруживаются Apache HTTP (порт 80), HTTPS (443), Samba SWAT (901), TLS-обёрнутый Nessus (1241), неопознанный сервис (3690), HTTP-сервер MX4J (8000) и Apache Tomcat (8080). Неопознанный сервис на порту 8000 проверяется ручным подключением через ncat с отправкой GET / HTTP/1.0 - ответ HTTP/1.0 200 OK с заголовком Server: MX4J-HTTPD/1.0 подтверждает HTTP.

Полное 65535-портовое сканирование с определением сервисов - штука медленная, особенно для больших списков хостов. Быстрый сканер naabu обнаруживает открытые порты и передаёт их Nmap для определения сервисов только на найденных портах: naabu -p - -rate 2000 -c 50 -retries 2 -warm-up-time 1 -silent -host 192.168.1.100 -nmap-cli 'nmap -sV -oX scan.xml'. Nessus тоже определяет HTTP-сервисы на произвольных портах и дополнительно проверяет известные уязвимости и конфигурацию TLS.

Виртуальные хосты и картирование сетевой инфраструктуры​

DNS позволяет связать один IP-адрес с несколькими именами. Виртуальный хост - механизм, при котором веб-сервер определяет приложение по заголовку Host в HTTP-запросе. IP 192.168.1.100 может обслуживать www.example.com, helpdesk.example.com и webmail.example.com - без информации о дополнительных именах тестировщик увидит только одно приложение. Остальные останутся невидимками.

Перечисление DNS для выявления точек входа злоумышленника​

Перечисление DNS направлено на выявление доменов, поддоменов и связанных записей целевой организации для расширения охвата оценки. За дополнительными виртуальными хостами могут скрываться среды разработки, staging-окружения, устаревшие сервисы или административные интерфейсы - всё то, что не попало в задание, но торчит наружу.

Пассивная DNS-разведка​

Пассивные методы не взаимодействуют с инфраструктурой цели и опираются на публичные источники: записи DNS (A, AAAA, MX, TXT, NS), обратные DNS-запросы (PTR), поисковые системы, пассивные DNS-базы, логи Certificate Transparency. На раннем этапе пассивные методы предпочтительны - меньше шума.

Subfinder - инструмент обнаружения поддоменов, работающий исключительно с пассивными онлайн-источниками: subfinder -d example.com -silent. Chaos (chaos-client) от ProjectDiscovery предоставляет курированный набор поддоменов из scope программ bug bounty, требует API-ключа, покрывает только проиндексированные домены и не заменяет subfinder или Amass для произвольных целей.

Веб-сервисы DNS-поиска работают аналогично zone transfer, но через веб-интерфейс: Netcraft Search DNS позволяет запросить список имён домена. Результаты частичны - используйте несколько сервисов. Reverse-IP сервисы решают обратную задачу: по IP ищут связанные доменные имена. Среди доступных - MxToolbox Reverse IP, ViewDNS.info Reverse IP, HackerTarget Reverse IP Lookup.

Поисковые системы по интернет-инфраструктуре - Shodan, Censys и FOFA - индексируют подключённые к интернету хосты и сервисы. Поиск по IP, сертификату или баннеру выявляет дополнительные имена и сервисы. FOFA хорошо покрывает инфраструктуру в Азиатско-Тихоокеанском регионе. Примеры: ip="192.168.1.100", title="Example App".

Результаты поисковых систем (Google, Bing) могут уточнить собранные данные. После обнаружения связанных доменов поиск по ним выявляет дополнительные имена и приложения на неочевидных URL. Техники поиска подробнее описаны в WSTG, раздел «Пауки, роботы и краулеры».

Активная DNS-разведка и перестановка поддоменов​

Активные методы напрямую обращаются к DNS-инфраструктуре цели и оставляют следы в журналах целевых систем: перебор поддоменов (brute forcing), попытки zone transfer, перечисление записей.

Типичные инструменты: Amass (проект OWASP, пассивный и активный режим, графовый вывод), subfinder, dnsrecon, fierce, dig, nslookup. Актуальная версия Amass на дату подготовки материала - v5.1.3. В Amass v5 пассивный режим работает по умолчанию: флаг -passive помечен как устаревший. Флаг -active включает попытки zone transfer и извлечение имён из сертификатов. Примеры CLI в WSTG соответствуют версии v5.1.1 - при расхождении с текущим интерфейсом сверяйтесь с документацией актуального релиза.

Пример запроса записей через dig: dig example.com ANY возвращает A, MX, NS, TXT и другие записи домена.

После сбора начального набора поддоменов техника перестановки (permutation) генерирует дополнительные кандидаты: комбинирует метки с типовыми префиксами и суффиксами, применяет мутации (dev- в staging-, вставку цифр). Инструменты: altdns, dnsgen, gotator. Полученные кандидаты разрешаются через dnsx или MassDNS (высокоскоростной резолвер для больших списков) и проверяются на доступность через httpx.

Zone transfer и обратные DNS-запросы​

Zone transfer (AXFR) позволяет запросить у DNS-сервера полный список записей зоны. Большинство серверов такие запросы отклоняют, но попытка ничего не стоит. Сначала определяются NS-серверы домена: host -t ns www.owasp.org. Затем запрашивается zone transfer: host -l www.owasp.org ns1.secure.net. Типичный ответ - REFUSED.

Согласно RFC 9499, авторитетный сервер - сервер, знающий содержимое DNS-зоны из локальных данных. Zone transfer раскрывает структуру DNS-записей, но не подтверждает факт владения активом и не гарантирует работу сервиса на найденном имени. Каждая обнаруженная запись требует отдельной проверки.

Обратные (inverse) DNS-запросы работают через PTR-записи: по IP-адресу запрашивается символьное имя. Метод зависит от наличия обратной карты IP-to-name, которая не гарантирована. Оба метода - zone transfer и inverse queries - исторические, с ограниченной применимостью в современных условиях, но входят в полный набор проверок. Активные запросы к DNS цели требуют соблюдения границ scope и правил engagement.

Цифровые сертификаты и прозрачность сертификатов​

Если сервер принимает HTTPS-подключения, поля Common Name (CN) и Subject Alternative Name (SAN) сертификата могут содержать дополнительные имена хостов. Извлечь их можно через OpenSSL: openssl s_client -connect 93.184.216.34:443 </dev/null 2>/dev/null | openssl x509 -noout -text | grep -E 'DNS:|Subject:'. Результат покажет имена вроде DNS:www.example.org, DNS:example.com, DNS:example.edu. При wildcard-сертификатах или самоподписанных сертификатах полезной информации может не быть.

Логи CT - публично доступные записи о выпущенных TLS-сертификатах. Согласно RFC 9162, CT-логи - это append-only журналы, фиксирующие факт выпуска сертификата. Сами по себе они не предотвращают и не обнаруживают неправомерный выпуск - для этого нужен мониторинг заинтересованными сторонами. Поиск по CT выявляет имена, недоступные через zone transfer, обратные запросы или поисковые системы: dev/staging среды, административные интерфейсы, устаревшие системы, wildcard-сертификаты.

Запрос к агрегаторам сертификатов: https://crt.sh/?q=%25.example.com. При недоступности crt.sh - альтернативы Merklemap и SSLMate Cert Spotter. Найденные имена валидируются DNS-резолвингом, подтверждается принадлежность и актуальность до начала тестирования.

Учебный пример: реестр активов из сертификата и DNS. Контекст: контролируемая DNS-зона лаборатории с одним устаревшим и одним рабочим поддоменом. Действия: собрать имена из сертификата и DNS, сверить владельца, проверить разрешённые HTTP-endpoints. Ожидаемый результат: реестр отличает историческое имя от активного приложения и фиксирует источник обнаружения. Отрицательный контроль: найденный в CT внешний домен не включается в активное тестирование автоматически - обнаружение записи в CT-логе подтверждает факт выпуска сертификата, а не владение активом или работоспособность сервиса.

Рабочий процесс: от пассивной разведки к активной проверке​

Типовой легковесный pipeline из WSTG-INFO-04:
Этапы: пассивное обнаружение поддоменов через subfinder и Amass; объединение, дедупликация и DNS-разрешение через dnsx; проверка live-хостов через httpx с определением технологий, заголовков и HTTP-кодов; сбор исторических URL через gau; визуальная сортировка скриншотами через gowitness. Httpx также поддерживает встроенный флаг -screenshot для скриншотов без дополнительных утилит.

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

Анализ точек входа в приложение​

Перечисление точек входа - то, без чего тестирование не начинается (WSTG-INFO-06). Цель: выявить возможные точки входа и инъекции через анализ запросов и ответов.

До начала тестирования разберитесь, как пользователь и браузер взаимодействуют с приложением. При обходе фиксируйте все HTTP-запросы и каждый параметр. Отмечайте использование GET, POST и других методов (PUT, DELETE) для RESTful-сервисов - редкие методы, если разрешены, часто открывают уязвимости. Для перехвата параметров в теле запросов нужен перехватывающий прокси (Burp Suite, ZAP, Fiddler). Результаты удобно вести в таблице: запрошенная страница, интересные параметры, тип запроса, аутентификация (есть/нет), TLS, многошаговый ли процесс, WebSockets, номер запроса в прокси.

Запросы: GET, POST и скрытые параметры​

Что фиксировать: места использования GET и POST; все параметры POST в теле (скрытые поля форм содержат состояние, количество, цену - изменение может повлиять на загруженные страницы и уровень доступа); параметры GET в query string в формате foo=bar, разделённые &, ~, : или спецсимволами; закодированные и зашифрованные параметры; нестандартные заголовки (например, debug: false).

Помимо классических форм, фиксируйте тело JSON-запросов (Content-Type: application/json) - параметры передаются как ключи объекта, и multipart-запросы (multipart/form-data) - используются для загрузки файлов и могут содержать как текстовые поля, так и бинарные данные. Все эти форматы ведутся в одном журнале точек входа.

Ответы и индикаторы архитектуры​

В ответах фиксируйте: установку, изменение или добавление cookie (заголовок Set-Cookie); перенаправления (3xx), запреты (403 Forbidden), ошибки сервера (500) при обычных запросах; нестандартные заголовки. Заголовок Server: BIG-IP указывает на балансировку нагрузки - уязвимый сервер может отвечать не на каждый запрос.

Пример GET-запроса покупки: GET /shoppingApp/buyme.asp?CUSTOMERID=100&ITEM=z101a&PRICE=62.50&IP=x.x.x.x с cookie SESSIONID=.... Точки входа: CUSTOMERID, ITEM, PRICE, IP и cookie.

Пример POST-запроса авторизации:
Параметры разбросаны по нескольким местам: service в query string; SESSIONID и CustomCookie в заголовке Cookie; user, pass, debug, fromtrustIP в теле запроса. Чем больше мест для инъекции - тем шире возможности для цепочки атаки.

Учебный пример: журнал точек входа. Контекст: локальное приложение с JSON API и загрузкой аватара за reverse proxy. Действия: перехватить штатные запросы, перечислить входы (URL-параметры, заголовки, cookie, тело JSON, multipart-поля загрузки), записать метод, формат входа, роль пользователя и обработчик для каждого, нарисовать поток к хранилищу. Ожидаемый результат: карта содержит роли, формат входа и границу доверия между proxy и backend. Отрицательный контроль: строка Server без иных доказательств не подтверждает наличие отдельного backend-сервера - это гипотеза, не факт.

Сопоставление с кодом при gray-box тестировании​

При доступе к исходному коду (gray-box или white-box) инструменты статического анализа обнаруживают эндпоинты, недоступные пауку. И вот тут начинается самое интересное - разница между тем, что написано в коде, и тем, что реально доступно снаружи.

OWASP Attack Surface Detector​

Attack Surface Detector (ASD) - инструмент статического анализа кода, обнаруживающий конечные точки веб-приложения, принимаемые параметры и их типы данных. ASD находит незалинкованные эндпоинты и необязательные параметры, отсутствующие в клиентском коде. Инструмент рассчитывает изменения поверхности атаки между двумя версиями приложения. Распространяется как плагин для ZAP и Burp Suite и как CLI-инструмент. CLI экспортирует поверхность атаки в JSON - полезно, когда исходный код не передаётся тестировщику: заказчик предоставляет JSON-файл.

Использование CLI: java -jar attack-surface-detector-cli-1.3.5.jar <путь-к-коду> [флаги]. На примере OWASP RailsGoat ASD обнаруживает 40 уникальных эндпоинтов и 36 параметров с указанием типа данных, типа параметра (QUERY_STRING, SESSION) и файла-обработчика с номерами строк. Флаг -json генерирует JSON-вывод для плагинов ZAP и Burp Suite.

OWASP Noir​

OWASP Noir - SAST-инструмент, извлекающий конечные точки из исходного кода статическим анализом. Для каждого эндпоинта сообщаются HTTP-метод и параметры из query string, тела запроса, пути, заголовков и cookie. Noir поддерживает 263 фреймворка, включая Rails, Django, Express, Spring и Laravel.

Использование: noir scan <путь-к-коду> [флаги]. На примере RailsGoat Noir обнаруживает 56 эндпоинтов с методом, путём и параметрами по местоположению (path, body, cookies). Некоторые легко пропустить при ручном обходе - например, cookie font, читаемое эндпоинтом /dashboard/home. Noir поддерживает выходные форматы plain text, JSON, OpenAPI, curl-команды. Формат curl генерирует по одной команде на эндпоинт: noir scan railsgoat --no-log -f curl -u http://localhost:3000. Флаг --probe-via отправляет каждый эндпоинт через перехватывающий прокси: noir scan railsgoat -u http://localhost:3000 --probe-via http://127.0.0.1:8080. Noir экспортирует документ OpenAPI для импорта в ZAP или Burp Suite.

Разница между результатами статического анализа и реально доступными маршрутами - критический момент. Статический анализ показывает, что написано в коде, но маршрут может быть закрыт middleware, ACL или конфигурацией сервера. Обнаруженные эндпоинты нужно проверять на фактическую доступность.

Карта архитектуры и анализ архитектуры безопасности​

Чтобы тестирование имело смысл, а рекомендации - вес, нужно понимать, что именно тестируется, и определить компоненты за рамками scope (WSTG-INFO-10). Современные веб-приложения варьируются от скрипта на одном сервере до зоопарка из десятков компонентов. Сетевые компоненты (firewall, IPS) могут существенно влиять на тестирование. Цель: понять архитектуру приложения и используемые технологии.

При black-box тестировании строится картина работы приложения. Некоторые компоненты (WAF) тестируются напрямую; другие определяются по поведению.

Прикладные компоненты​

Веб-сервер. Простые приложения работают на одном сервере, определяемом методами fingerprint (WSTG, раздел Fingerprint Web Server).

PaaS. Инфраструктура управляется провайдером; владелец отвечает за приложение. Тестирование инфраструктуры обычно out-of-scope. PaaS определяется по домену: Azure App Services - *.azurewebsites.net (возможны кастомные домены).

Serverless. Код выполняется как отдельные функции на платформе. Тестирование инфраструктуры обычно out-of-scope. AWS Lambda возвращает характерные заголовки: X-Amz-Invocation-Type, X-Amz-Log-Type, X-Amz-Client-Context. Azure Functions используют заголовок Server: Kestrel, но он не уникален. Согласно документации AWS, безопасность делится по модели разделённой ответственности: AWS отвечает за инфраструктуру, клиент - за код, конфигурацию и политики доступа.

Микросервисы. API состоит из дискретных сервисов, часто в контейнерах (Kubernetes). Разные языки в сообщениях об ошибках - косвенный признак микросервисной архитектуры. Обычно за единым API-шлюзом. При использовании service mesh (Istio) учитывайте: авторизационные функции Istio доступны после установки без явного включения, однако при отсутствии применённых политик авторизации Istio по умолчанию разрешает все запросы. Наличие service mesh не гарантирует ограничения доступа без явных политик - это гипотеза, требующая проверки.

Статическое хранилище. Amazon S3 (BUCKET.s3.amazonaws.com или s3.REGION.amazonaws.com/BUCKET) и Azure Storage Accounts (ACCOUNT.blob.core.windows.net). Могут раскрывать чувствительные файлы.

База данных. Определяется сканированием портов (характерные для БД) или провоцированием SQL/NoSQL-ошибок. Эвристики: Windows/IIS/ASP.NET → Microsoft SQL Server; встраиваемые системы → SQLite; PHP → MySQL или PostgreSQL; APEX → Oracle.

Аутентификация и сторонние сервисы​

Аутентификация. Конфигурация сервера (.htaccess, HTTP Basic с WWW-Authenticate: Basic); локальные учётные записи в БД (форма или API); Active Directory или LDAP (NTLM с WWW-Authenticate: NTLM, формат DOMAIN\username); SSO (OAuth, OpenID Connect, SAML). Приложение может предлагать несколько способов с разными механизмами для пользователей и администраторов.

Сторонние сервисы и API. Активный контент (скрипты, стили, шрифты, iframe), пассивный (изображения, видео), внешние API, соцсети, рекламные сети, платёжные шлюзы. Запрашиваются браузером напрямую, обнаруживаются через DevTools или прокси. Их нужно идентифицировать (влияют на безопасность), но обычно они out-of-scope - принадлежат третьим сторонам.

Сетевые и защитные компоненты на периметре безопасности​

Сетевые компоненты​

Reverse proxy перед backend-серверами: балансировка, WAF, размещение нескольких приложений на одном IP, IP-фильтрация, кэширование. Обнаружение: несоответствие frontend-сервера и backend (заголовок Server: nginx при ASP.NET - возможен request smuggling); дублирование заголовков; разные приложения на одном IP.

Балансировщик нагрузки распределяет запросы между backend-серверами. Признаки: несогласованное системное время, разные внутренние IP в ошибках, разные адреса при SSRF, характерные cookie (F5 BIG-IP - BIGipServer).

CDN - распределённая сеть кэширующих прокси. Определяется WHOIS-запросом IP: принадлежность Akamai, Cloudflare, Fastly указывает на CDN. При тестировании: IP и серверы принадлежат провайдеру (out-of-scope); CDN включает bot detection, rate limiting, WAF; контент кэшируется. Backend-серверы можно искать через email-заголовки, DNS grinding, certificate transparency, сканирование IP-диапазонов, SSRF, детальные ошибки.

Компоненты безопасности​

Сетевой firewall. Порты «закрыты» (RST на SYN) - firewall, вероятно, отсутствует; порты «фильтруются» (нет ответа на SYN) - firewall работает. Открытые нецелевые сервисы (SMTP, IMAP, MySQL) указывают на отсутствие или кривую настройку firewall.

IDS/IPS. IDS обнаруживает подозрительную активность (сканирование портов, уязвимостей), IPS блокирует. IPS обнаруживается при блокировке IP после автоматического сканирования. Многие прикладные инструменты не детектируются IPS, особенно без расшифровки TLS.

WAF инспектирует HTTP-запросы, блокирует подозрительные. Использует сигнатуры и регулярные выражения (OWASP Core Rule Set). Эффективен против SQLi и XSS, менее - против атак на бизнес-логику. Развёртывание: на сервере, отдельном устройстве, в облаке. Обнаруживается тестовыми строками в параметрах: ' UNION SELECT 1 или ><script>alert(1)</script>. Блокировка, содержимое страницы блокировки, специфические cookie или заголовки указывают на WAF. Облачный WAF обходится прямым доступом к backend.

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

Пропуски и допущения: гипотеза против факта​

Карта поверхности атаки никогда не бывает полной. Неизвестный origin за CDN, устаревшие DNS-записи на несуществующий сервер, сторонние сервисы с непрозрачной архитектурой - всё это сохраняется в реестре как открытый вопрос, а не как установленный факт.

Две типичные ошибки:

1. Расширение scope по любому найденному имени. DNS-запись или запись в CT-логе не подтверждает владение и не даёт права на тестирование. Каждый обнаруженный актив проходит проверку принадлежности до включения в активное тестирование.
2. Изображение предполагаемых компонентов как факта. Заголовок Server: nginx при ASP.NET - гипотеза о reverse proxy, не факт. На карте такие компоненты помечаются вопросом и требуют дополнительных доказательств.

Исправления и защита​

Инвентаризация активов и поверхности атаки​

Защитное действие: вести актуальный реестр всех доменов, поддоменов, виртуальных хостов, приложений и их владельцев. Каждый актив получает запись с источником обнаружения (DNS, CT, сканирование портов), датой последней проверки и ответственным лицом.

Сохраняемый результат: документ или база данных с полным перечнем активов, статусом (активный, устаревший, под вопросом) и назначенным владельцем. Активы без владельца подлежат назначению или выводу из эксплуатации.

Способ проверки: периодически повторять процедуру обнаружения (passive-to-active pipeline) и сравнивать с реестром. Новые активы, не зафиксированные в реестре, - сигнал для расследования. Ожидаемый результат повторной проверки: отсутствие расхождений между реестром и фактически обнаруженными активами.

Снижение сетевой доступности и документирование границ доверия​

Защитное действие состоит из двух частей. Первая - ограничение ненужных сервисов и направлений доступа: закрыть порты, не требуемые для работы; убрать из публичного доступа административные интерфейсы (Tomcat Manager, SWAT, отладочные эндпоинты); ограничить staging/dev среды по IP или VPN. Вторая - документирование границ: зафиксировать зоны (внешний периметр, DMZ, внутренняя сеть, среды разработки), разрешённые сетевые потоки между ними и ответственных за каждую зону.

Сохраняемый результат: диаграмма архитектуры с подписанными границами доверия, разрешёнными потоками и списком ответственных; конфигурация firewall, соответствующая документации.

Способ проверки: повторное сканирование портов и сопоставление с ожидаемым результатом. Обнаруженный порт или сервис, отсутствующий в документации разрешённых потоков, - сигнал для закрытия доступа или обоснования исключения. Затем проверяется, что закрытие лишнего доступа не нарушило работу разрешённых потоков.

Инструменты​

Сводный перечень из WSTG-INFO-04, WSTG-INFO-06 и WSTG-INFO-10:

DNS и обнаружение поддоменов: nslookup, dig, host; Amass (OWASP - пассивный + активный, граф); subfinder; Chaos/chaos-client (курированный набор, API-ключ); dnsrecon, fierce; dnsx; MassDNS.

Перестановка поддоменов: altdns, dnsgen, gotator.

Проверка live-хостов и скриншоты: httpx (проверка хостов, определение технологий); gowitness (визуальная сортировка).

Сканирование портов: Nmap; naabu (быстрое сканирование, интеграция с Nmap); Nessus; Nikto.

Перехватывающие прокси: ZAP, Burp Suite, Fiddler.

Обнаружение контента и параметров: ffuf, feroxbuster, gobuster, Arjun.

Краулеры: katana, hakrawler.

Исторические URL: gau, waybackurls, waymore.

Статический анализ для обнаружения эндпоинтов: OWASP Noir, OWASP Attack Surface Detector.

CT-поиск: crt.sh, Merklemap, SSLMate Cert Spotter.

Поисковые системы по инфраструктуре: Shodan, Censys, FOFA.

Инструменты API-разведки (Kiterunner, LinkFinder, jsluice, xnLinkFinder, Param Miner) перечислены в WSTG, раздел API Reconnaissance. WSTG-INFO-06 ссылается на RFC 2616 (HTTP/1.1) и проект OWASP Attack Surface Detector.

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

Основа: OWASP Web Security Testing Guide, OWASP Foundation и авторы соответствующих материалов.

Исходные материалы (снимки от 2026-11-04):

• WSTG-INFO-04 - Attack Surface Identification
• WSTG-INFO-06 - Identify Application Entry Points
• WSTG-INFO-10 - Map Application Architecture

Русский перевод и редакционная актуализация - Codeby. Изменения: три проверки WSTG объединены в один рабочий процесс; добавлены учебные примеры с лабораторным контекстом; раздел инструментов сведён в единый перечень; уточнена актуальная версия Amass (v5.1.3); добавлены ссылки на RFC 9162 о природе CT-логов и RFC 9499 об авторитетных DNS-серверах; добавлены пояснения о поведении Istio и AWS Lambda по данным их документации.

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

Большая часть команд, собирающих данные о поверхности атаки, не требует привилегий - достаточно рабочей станции и разрешения на тестирование. Защита строится не на скрытии компонентов, а на контролируемой поверхности с документированными границами. Типичная реакция на предложение автоматизировать инвентаризацию - «у нас есть CMDB». Формально - да. Но CMDB описывает инфраструктуру на момент последнего аудита, а поверхность атаки живёт в реальном времени: новые поддомены, staging-среды на временных адресах, сторонние интеграции без уведомления ИБ-отдела. Разрыв между реестром и фактической поверхностью - неучтённый риск. Pipeline пассивно-активной разведки, запускаемый по расписанию против собственных доменов, закрывает этот разрыв надёжнее любого ежеквартального пересмотра. Только не стоит путать наличие записи в DNS или CT-логе с подтверждением, что сервис работает, принадлежит организации и принимает трафик - это три разных факта, каждый из которых проверяется отдельно. Карта архитектуры, на которой предполагаемые компоненты помечены как факт, опаснее отсутствия карты: она создаёт ложное чувство контроля.

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