Кейс: как мы автоматизировали генерацию Nuclei-шаблонов для VK API с помощью LLM
Представьте, что у вас есть огромное количество новых методов в API, и вы хотите быстро и качественно тестировать их на уязвимости. Вручную это делать невозможно — слишком долго и скучно. Вот почему мы решили автоматизировать генерацию Nuclei-шаблонов на основе JSON-схем методов VK API, используя LLM.
🔹 Но задача оказалась не такой простой. Например, для создания комментария нужно сначала получить `postId`, а для этого вызвать другой метод. Как автоматически определить, какие данные нужны для каждого метода? И как понять, какие параметры можно использовать для тестирования уязвимостей, а какие — нет? Ведь не все поля одинаково «безопасны» для нагрузки.
Еще одна сложность — не всегда достаточно просто вызвать метод: иногда уязвимость проявится только после ряда действий на странице (например, открытие модального окна, клик по кнопке). Раньше такие сценарии писали вручную, но это не масштабируется. Мы искали способ автоматически собирать эти действия и использовать их для обучения LLM.
В итоге мы выбрали такой подход:
▫️автоматически собираем актуальные методы VK API, чтобы всегда иметь самую свежую информацию;
обучаем LLM анализировать JSON-схемы, чтобы определять, какие параметры использовать для нагрузки, а какие — оставить в покое;
▫️обогащаем модель контекстом: используем не только схемы методов, но и реальный трафик тестировщиков, а также автотесты, чтобы модель понимала, как методы применяются на практике;
▫️запускаем бота на Selenium, который «проживает» основные пользовательские сценарии, чтобы фиксировать, какие методы используются на каких страницах;
▫️для сложных сценариев, где методы вызываются не напрямую, собираем скрипты действий, чтобы расширить контекст обучения;
▫️всё это позволяет нам избегать «галлюцинаций» — когда модель начинает выдумывать что-то лишнее — и поддерживать нужный баланс между информативностью и точностью.
Не обошлись без LLM и при выборе триггера сканирования. Как только завершаются функциональные тесты в пайплайне, в дело вступает модуль скоринга «фичи» на базе LLM. Модуль оценивает её на предмет существенности изменений: если фича больше про косметические правки, не затрагивает бизнес-логику, не порождает новых полей для пользовательского ввода, etc, то необходимости сканировать её нет.
🔹Генерация Nuclei-шаблонов стала быстрой, масштабируемой и автоматической. Теперь мы можем быстро реагировать на появление новых методов, и количество тестов выросло в разы, а рутинная ручная работа — уменьшилась.
Но, конечно, не всё идеально: сложные user flows, вопросы с контекстом и галлюцинации — всё это мы учли и продолжаем дорабатывать.
🔹Если у вас есть вопросы по нашему подходу или хотите обсудить детали — пишите!
Представьте, что у вас есть огромное количество новых методов в API, и вы хотите быстро и качественно тестировать их на уязвимости. Вручную это делать невозможно — слишком долго и скучно. Вот почему мы решили автоматизировать генерацию Nuclei-шаблонов на основе JSON-схем методов VK API, используя LLM.
🔹 Но задача оказалась не такой простой. Например, для создания комментария нужно сначала получить `postId`, а для этого вызвать другой метод. Как автоматически определить, какие данные нужны для каждого метода? И как понять, какие параметры можно использовать для тестирования уязвимостей, а какие — нет? Ведь не все поля одинаково «безопасны» для нагрузки.
Еще одна сложность — не всегда достаточно просто вызвать метод: иногда уязвимость проявится только после ряда действий на странице (например, открытие модального окна, клик по кнопке). Раньше такие сценарии писали вручную, но это не масштабируется. Мы искали способ автоматически собирать эти действия и использовать их для обучения LLM.
В итоге мы выбрали такой подход:
▫️автоматически собираем актуальные методы VK API, чтобы всегда иметь самую свежую информацию;
обучаем LLM анализировать JSON-схемы, чтобы определять, какие параметры использовать для нагрузки, а какие — оставить в покое;
▫️обогащаем модель контекстом: используем не только схемы методов, но и реальный трафик тестировщиков, а также автотесты, чтобы модель понимала, как методы применяются на практике;
▫️запускаем бота на Selenium, который «проживает» основные пользовательские сценарии, чтобы фиксировать, какие методы используются на каких страницах;
▫️для сложных сценариев, где методы вызываются не напрямую, собираем скрипты действий, чтобы расширить контекст обучения;
▫️всё это позволяет нам избегать «галлюцинаций» — когда модель начинает выдумывать что-то лишнее — и поддерживать нужный баланс между информативностью и точностью.
Не обошлись без LLM и при выборе триггера сканирования. Как только завершаются функциональные тесты в пайплайне, в дело вступает модуль скоринга «фичи» на базе LLM. Модуль оценивает её на предмет существенности изменений: если фича больше про косметические правки, не затрагивает бизнес-логику, не порождает новых полей для пользовательского ввода, etc, то необходимости сканировать её нет.
🔹Генерация Nuclei-шаблонов стала быстрой, масштабируемой и автоматической. Теперь мы можем быстро реагировать на появление новых методов, и количество тестов выросло в разы, а рутинная ручная работа — уменьшилась.
Но, конечно, не всё идеально: сложные user flows, вопросы с контекстом и галлюцинации — всё это мы учли и продолжаем дорабатывать.
🔹Если у вас есть вопросы по нашему подходу или хотите обсудить детали — пишите!