AI-агент прошёл по тестовому приложению и отметил находку: утечка персональных данных, верификатор её подтвердил. При ручной проверке выясняется, что эти данные публичные и доступны любому посетителю сайта. Ложные находки появляются, когда модели не хватает контекста о цели, правилах работы и о том, что вообще считать уязвимостью. Разбираем, что рассказать ей до первого запроса и как проверять её выводы.
А сверить свой подход с практикой можно на бесплатном воркшопе 3 ноября: там учебные веб-таски эксперт решит вручную и с помощью AI.
Почему модель находит то, чего нет
Модель видит запросы и ответы приложения, но не знает договорённостей с заказчиком и логики бизнеса. Данные, которые компания публикует сознательно, для неё выглядят как утечка, пока ей прямо не скажут обратное.
Отдельная роль проверяющего решает проблему лишь частично. В агентских системах модель сама запускает инструменты и отправляет запросы, а другая роль подтверждает находки. Но и верификатор может согласиться с «утечкой», не проверив, доступны ли данные всем. Отправлять такие результаты без ручной проверки рискованно: на баг-баунти-площадках участники, которые дают агенту сессию и позволяют ему самому отправлять отчёты, получают отрицательный рейтинг.
Что рассказать модели до первого запроса
Контекст лучше собрать заранее и передавать в начале каждой сессии. Минимальный набор:
- Скоуп. Какие домены и IP можно трогать. В агентских системах для этого делают отдельную проверку: перед переходом на новый адрес агент спрашивает человека, входит ли он в скоуп.
- Правила. Условия договора или программы баг-баунти. В баг-баунти достаточно дать ссылку на правила программы, модель прочитает ограничения сама.
- Что считать уязвимостью. Например, какие данные публичны по замыслу и утечкой не являются.
- Исходные материалы. HTTP-запрос и ответ, фрагмент кода, описание функции. Чем меньше модели приходится додумывать, тем меньше ложных находок.
- Стек. Попросите сначала определить, на чём написано приложение, и проверять уязвимости, характерные для этого стека, включая известные CVE.
- Подсказки по нестандартным путям. Модель не всегда сама догадается, куда смотреть. Если приложение принимает XML, прямо предложите проверить векторы XXE.
- Окружение. Проверьте, с какими настройками модель запускает инструменты: например, подключены ли API-ключи у утилиты поиска поддоменов. Модель может и сама подсказать, что нужно донастроить.
Задача для модели: гипотеза, которую можно проверить
На простых учебных задачах модели часто хватает описания и ссылки на стенд. В реальном проекте полезнее строить работу циклом: наблюдение, гипотеза, проверка. Модель фиксирует, что увидела в ответе приложения, предлагает объяснение и подтверждает его конкретным запросом.
Вот как это выглядит на учебной задаче с внедрением команд. Приложение возвращает введённую строку в Base64 и вырезает часть символов. Если отправлять спецсимволы по одному, видно, что скобки запрещены, пробелы и точки удаляются, а знак доллара проходит. Отсюда гипотезы: команду можно внедрить через обратные кавычки, пробел заменить переменной IFS, а точку в имени файла обойти маской. Модель, которой дали ту же задачу, прошла похожий путь: распознала Base64, выполнила команду id через обратные кавычки, обошла запрет пробела через IFS и сама заметила, что точки вырезаются.
В каждом шаге просите модель показывать отправленный запрос и фактический ответ приложения. Вывод без такого ответа помечайте как гипотезу и проверяйте отдельно.
Тот же цикл на SQL-инъекции, XSS, SSTI и NoSQL-инъекции в MongoDB, с моментами, где модель пришлось поправлять, можно посмотреть на практическом разборе 3 ноября.
Правила безопасной эксплуатации
Модели обычно эксплуатируют аккуратно, даже когда ограничения не прописаны. Но гарантии нет ни в этом случае, ни после того, как правила прописаны. Поэтому их задают заранее, а за активной эксплуатацией следят:
- XSS подтверждать выводом в консоль, без alert на всю страницу.
- Не удалять аккаунты и данные.
- Получив доступ к базе, не читать её целиком: для доказательства хватит нескольких строк.
- При RCE ограничить набор команд и не уходить дальше во внутреннюю сеть.
- Найдя SSRF, остановиться, сообщить о находке и спросить, что делать дальше.
- Отдельно оговорить секреты и данные клиента.
Как проверять находки
Воспроизведите запрос сами. Удобнее всего в Burp Suite. Если подключить Burp к модели через MCP-сервер (протокол, через который модели получают доступ к инструментам), она сможет сама смотреть HTTP-историю и добавлять находки в Repeater. Повторить запрос и прочитать ответ всё равно нужно самому.
Используйте несколько проверок. В агентской системе можно запускать трёх верификаторов на одну уязвимость и продолжать проверку, пока они не придут к единому решению. Так ложных срабатываний становится меньше.
Соберите доказательства. Модели хорошо пишут PoC и умеют делать скриншоты. Это пригодится на баг-баунти-площадках: многие из них требуют скриншоты и видео воспроизведения.
Если сил на всё не хватает, проверяйте вручную хотя бы две вещи: триаж уязвимостей и скоуп.
Что отдать модели, а что оставить себе
Лучше всего модели справляются с разведкой: пассивное и активное сканирование сводится к запуску консольных утилит, а с командной строкой агенты работают уверенно. На такие задачи можно назначать лёгкие модели и не тратить токены на тяжёлые. Ещё одна сильная сторона: PoC и рутина вроде подготовки запросов с нагрузками.
Свою методологию можно упаковать в скиллы. Скилл представляет собой развёрнутый промпт с целью, этапами и конкретными инструкциями. Например, отдельный скилл под GraphQL описывает, как проверять интроспекцию и что делать, если её блокирует файрвол. Модель берёт такой скилл и действует по вашей методологии.
Триаж, решения по скоупу и финальная проверка остаются за человеком. В пентесте AI пока работает как второй пилот, и рядом с ним нужен триажер с опытом. В компаниях, которые проверяют защищённость собственных продуктов, внедрение идёт медленнее: продвинутые модели во внутреннюю инфраструктуру не пускают, опасаясь за персональные данные и саму инфраструктуру.
Разбор на практике
3 ноября в 19:00 МСК CyberED проводит воркшоп «Разбор и решение тасок по пентесту и сравнение с AI». Специалист по анализу защищённости Никита Коломиец решит четыре учебные веб-таски на SQL-инъекцию, XSS, SSTI и NoSQL-инъекцию в MongoDB: от анализа условия до получения флага. В отдельных шагах он подключит AI и покажет, что предложила модель, как это проверили и что пришлось уточнить.
Сложность Easy. Пригодится знание HTTP, GET/POST, JSON и cookies, а для одной из задач понадобится читать простой Python-код. Зарегистрироваться на воркшоп.
