Техники перечисления

Сначала граница: только лаборатория, и перечисление — это разведка

Прежде всего о механиках: всё ниже рассчитано на систему, которой вы владеете или которую вам явно разрешено тестировать, — CTF-стенд, намеренно уязвимое приложение в вашей собственной VM, согласованный по объёму проект. Перечисление обращается к реальным эндпоинтам и реальным аккаунтам, поэтому без письменной авторизации и определённого scope это неавторизованный доступ, точка. Здесь нет вооружённых скриптов; цель — понять механизм достаточно глубоко, чтобы обнаруживать и притуплять его на системах, которые вы защищаете.

В последовательности атакующего перечисление — это разведка, первая тактика MITRE ATT&CK (TA0043). Само по себе оно не даёт пробоя. Оно даёт карту: какие пути существуют, какие имена пользователей реальны, какие объекты API можно назвать. Каждая последующая стадия дешевле и тише, потому что перечисление сузило поиск с «всего интернета» до «вот этих сорока вещей». Именно поэтому притупление перечисления имеет несоразмерно высокую защитную ценность — вы повышаете стоимость фундамента, на котором строится вся остальная атака.

Перечисление эндпоинтов: найти то, на что нет ссылок

Первая цель — структура. Карта сайта приложения показывает парадную дверь; перечисление ищет двери, на которые никогда не было ссылок, — /admin, /api/internal, /.git/config, /backup.zip, старую /v1, которую должны были вывести из эксплуатации. Техника — это перебор директорий и контента: берётся список частых путей и имён файлов, каждый запрашивается, и по HTTP-статусу и размеру ответа отличается «это существует» от «этого нет».

Сигнал, который читает атакующий, — это разница в ответах. Аккуратное приложение возвращает 404 на всё, чего нет. Дырявое возвращает 403 Forbidden на /admin (подтверждая, что путь существует, но защищён), 200 на /api/internal/users (существует и не защищён) и редирект 301, тихо раскрывающий реальный путь. Размер ответа важен не меньше статуса: типовая страница 404 имеет фиксированную длину, поэтому 404 с другой длиной часто оказывается реальной страницей в чужом статус-коде. Вся игра — в чтении этих признаков на тысячах запросов.

Перечисление пользователей и API: подтвердить, кто и что существует

Вторая цель — личности и объекты. Перечисление пользователей — это история формы входа из вступления: любое место, где приложение ведёт себя по-разному для реального и фальшивого аккаунта, — это оракул. Классические признаки — отдельное сообщение об ошибке («email не найден» против «неверный пароль»), другой HTTP-ответ и — самый тонкий — разница в тайминге. Если реальный аккаунт запускает дорогое хеширование пароля (bcrypt, argon2), а несуществующий возвращается мгновенно, потому что хешировать нечего, то одно лишь время ответа отделяет реальное от фальшивого даже при одинаковых сообщениях. Потоки регистрации и сброса пароля утекают так же («этот email уже зарегистрирован»).

Перечисление API обобщает это на объекты. REST API по адресу GET /api/orders/1001 напрашивается на вопрос: а что насчёт 1002, 1003, 1000000? Последовательные целочисленные ID позволяют атакующему пройти всю коллекцию простым счётом. Даже когда контроль доступа корректен и каждый запрос отклоняется, шаблон отказов размечает, какие ID существуют (403 на реальный, но запрещённый заказ, 404 на пробел), а подробные тела ошибок, утёкший документ OpenAPI/Swagger или introspection-запрос GraphQL выдают модель объектов целиком.

Что притупляет это: лимиты запросов и мониторинг

Определяющая слабость перечисления — объём. Подтверждение скрытых путей, валидных пользователей или объектов API требует от сотен до миллионов запросов, потому что атакующий ищет в пространстве, а не эксплуатирует одну известную брешь. Вот рычаг, за который тянут защитники.

Лимиты запросов бьют прямо по стоимости. Ограничьте запросы на IP, на аккаунт и на эндпоинт — и перебор, который должен был занять минуты, теперь занимает дни, достаточно долго, чтобы окно проекта закрылось или атакующий ушёл. Зрелый нюанс — где ограничивать: лимиты на IP тривиально обходятся ботнетом или ротацией прокси, поэтому высокоценные оракулы (вход, сброс пароля, эндпоинты токенов) нуждаются ещё и в лимитах на аккаунт и в глобальных потолках, плюс экспоненциальный backoff и CAPTCHA или proof-of-work на подозрительном пути. Лимиты редко делают перечисление невозможным; они делают его достаточно медленным, чтобы оно стало непрактичным, и достаточно громким, чтобы его заметили.

Мониторинг бьёт по скрытности. У перечисления есть отпечаток, которого нет у нормального трафика: один источник, генерирующий поток 404, прогон по последовательным ID, сотни неудачных входов по множеству имён пользователей или частота запросов, которую не выдаёт человек. Алертите на эти паттерны — всплески доли 4xx, доступ к путям или ID высокой кардинальности от одного клиента, всплески неудачной аутентификации — и вы обнаружите стадию разведки до того, как она перерастёт в эксплойт. Это выгода kill chain в миниатюре: перечисление — самая дешёвая, ранняя стадия атакующего, поэтому поймать её здесь — самое дешёвое, раннее место, чтобы разорвать цепочку.