LLM для аудиту безпеки: як тестувати веб‑сайти за допомогою штучного інтелекту

Вересень 2025 року.

Large Language Models (LLM) на кшталт ChatGPT, Claude та Google Gemini дедалі активніше застосовуються для аудиту безпеки веб-сайтів. Такі моделі можуть аналізувати код і поведінку веб-додатків, імітуючи мислення досвідченого аналітика з безпеки.

Наприклад, існують проєкти на зразок Rogue – це інтелектуальний сканер вразливостей, що використовує GPT-4 для виявлення та перевірки веб-вразливостей, генеруючи тестові атаки подібно до роботи людини-пентестера github.com. На відміну від традиційних сканерів, які діють за фіксованими шаблонами, LLM-рішення здатні “думати” нестандартно, підбираючи контекстно-залежні тестові сценарії і навіть автономно перевіряти знайдені проблеми. Зокрема, Rogue вміє розуміти контекст застосунку, генерувати спеціалізовані небезпечні запити, аналізувати відповіді та формувати детальні звіти про вразливості з кроками для відтворення атаки. Також передбачено автоматизоване розширення області перевірки (наприклад, сканування піддоменів і всіх виявлених сторінок) для повнішого охоплення github.com.

Новітні дослідження підтверджують ефективність GPT-4 у таких завданнях. Згідно зі звітом IBM, агент на базі GPT-4 з доступом до інструментів (веб-браузера, терміналу тощо) зміг успішно експлуатувати 87% відомих “one-day” вразливостей (вразливостей, інформація про які вже публічно доступна) – це значно краще за інші інструменти та попередні моделі ibm.com. Водночас GPT-3.5 не впорався із завданням виявлення/експлуатації жодної з цих вразливостей, а класичні сканери теж не змогли провести експлойт. Це вказує, що LLM-агенти за правильного підходу вже здатні перевершувати традиційні засоби. Однак, важливо зазначити, що LLM потребує деталізованого промпту та достатнього контексту для досягнення таких результатів: без підказок про конкретну уразливість або CVE його успішність різко падає (в експерименті успішність GPT-4 знизилася з 87% до 7%, якщо не надавати йому опису CVE)ibm.com. Це означає, що модель сама по собі не здогадається про всі проблеми – їй потрібні або підказки, або інтеграція зі сторонніми базами знань.

Anthropic Claude та інші моделі теж можуть бути корисними. Claude вирізняється дуже великим контекстним вікном (десятки тисяч токенів), що дозволяє завантажити в модель великі обсяги коду сайту чи логів для аналізу. Це зручно для статичного аналізу вихідного коду: Claude чи GPT-4 можуть перечитати код і знайти потенційно небезпечні місця, SQL-ін’єкції, XSS, неправильну обробку автентифікації тощо. Насправді, спільнота вже відзначала, що ChatGPT є продуктивним інструментом для різних задач кібербезпеки – від написання експлойтів і правил фаєрволу до пошуку вразливостей та генерації звітівcoronatodays.com. Проте якість аналізу LLM не ідеальна: як показав експеримент з аналізу смарт-контракту, GPT-4 знайшов 2 з 3 закладених вразливостей, але згенерував багато хибних спрацьовувань (фальшивих попереджень)mixbytes.io. Число хибних сповіщень може бути значним – моделі часто перестраховуються і вказують на потенційні проблеми, які в реальності не є вразливостямиmixbytes.io. Тому результати, надані LLM, потребують перевірки фахівцем, перш ніж робити висновки чи тим більше вносити зміни на основі цих порад.

Загалом, LLM доповнюють традиційні підходи до аудиту безпеки, але не замінюють їх повністю. Найкращий ефект досягається при поєднанні: LLM можна доручити рутинні перевірки і складання чернетки звіту, а спеціалізовані сканери (OWASP ZAP, Nessus, Nikto тощо) – глибинне сканування, після чого модель зведе результати в читабельний звіт. Також можливе підключення зовнішніх сервісів через інтерфейси чи плагіни: наприклад, існують експериментальні ChatGPT-плагіни для кібербезпеки, що напівавтоматично запускають сканування коду на вразливості та перевірку відповідності стандартамcybervizer.com cybervizer.com. Такий плагін може сам виконати сканер у фоновому режимі, а потім передати результати в модель для аналізу й пояснення. Подібні інтеграції роблять аудит майже повністю автоматичним: достатньо вказати домен або завантажити код, і LLM-асистент запустить перевірку, проаналізує всі сторінки, спробує знайти адмін-панель, а потім надасть структурований звіт із висновками.

Приклади промптів для аудиту безпеки сайту

Нижче наведено кілька корисних шаблонів промптів, які можна застосувати в ChatGPT, Claude чи аналогічній LLM. Вони розраховані на те, що ви підставите адресу свого сайту або вставите фрагменти коду, а модель проведе перевірку і згенерує корисний результат. З цих прикладів далі буде сформовано універсальний промпт для комплексного аудиту.

1. Промпт для автоматизованого сканування веб-сайту на вразливості

Промпт: “Виступай у ролі експерта з кібербезпеки (пентестера) найвищого рівня. Проведи аудит безпеки веб-сайту [URL сайту]. Тобі потрібно автоматично просканувати всі сторінки цього сайту, виявити можливі вразливості та слабкі місця безпеки. Зокрема:
– Виконай рекогносцію: визнач технології та мовні фреймворки, що використовуються на сайті (CMS, бібліотеки JavaScript, серверне ПЗ тощо). Проаналізуй публічні сторінки та виявив всі точки входу (форми, поля введення, параметри URL), які можуть бути вразливі.
– Перевір заголовки безпеки HTTP-відповідей (Content-Security-Policy, X-Frame-Options, etc.) та конфігурацію SSL/TLS сертифікату, повідомив про небезпечні налаштування або їх відсутність.
– Спробуй знайти сторінки адміністративної панелі чи входу (наприклад, /admin, /login, /wp-admin та подібні). Перевір, чи вони доступні без автентифікації і чи не виставлені випадково назовні.
– Для кожної знайденої вразливості або проблеми опиши: де вона виявлена, у чому полягає (наприклад, можливість SQL-ін’єкції, XSS, витік інформації через заголовки, застаріле ПЗ з відомими CVE тощо), та яку небезпеку несе.
– Оціни критичність кожної проблеми (низька, середня, висока) і обґрунтуй чому.
– Визнач загальний рівень безпечності сайту за десятибальною шкалою, де 10 – ідеальна безпека, 1 – вкрай незахищений. Врахуй кількість і серйозність знайдених вразливостей.
– Підготуй звіт у форматі PDF (неформально: можна у вигляді структури Markdown, яку легко конвертувати в PDF). У звіті створив розділи: Опис знайдених вразливостей (список з деталями), Оцінка безпеки (загальний скор і короткий висновок), а також Рекомендації.
– У розділі рекомендацій наведи покроковий план усунення кожної знайденої вразливості: які дії треба виконати розробникам або адміністраторам (наприклад, оновити версію CMS, виправити валідацію вводу, змінити налаштування сервера). Якщо якийсь пункт не застосовний – можеш його опустити.”*

(Примітка: Заміни [URL сайту] на адресу цільового сайту. У разі потреби модель може уточнювати деталі про технології сайту чи виконувати додаткові запити.)

Цей промпт орієнтований на максимально повну автоматичну перевірку. Він задає моделі конкретні кроки – від збору інформації до аналізу типових вразливостей OWASP Top 10 – і вимагає оформити професійний звіт. За можливості, слід виконувати його в середовищі, де LLM має доступ до інтернету або до даних сайту (наприклад, ChatGPT з ввімкненим браузером, чи інтеграція через інструменти на кшталт AutoGPT). Модель спробує сканувати всі сторінки, тому в реальності може знадобитися надати їй список URL (якщо вона сама не знайде). Очікуваний результат – структурований звіт, який можна зберегти як PDF. Ви отримаєте перелік знайдених проблем із поясненнями, рейтинг безпеки сайту та рекомендації щодо усунення недоліків. Такий вихід можна використати як чорновий варіант звіту з аудиту безпеки для замовника.

2. Промпт для перевірки вихідного коду веб-додатку

Якщо у вас є доступ до вихідного коду сайту (бекенд чи фронтенд скрипти), варто провести статичний аналіз коду за допомогою LLM. Ось шаблон запиту для цього:

Промпт: “Ти – експерт з безпеки коду з багаторічним досвідом. Проаналізуй наведений код веб-додатку (або його фрагмент) на предмет вразливостей та поганих практик. Код буде подано нижче.
Оціни код рядок за рядком, знаходячи потенційні проблеми: SQL-ін’єкції, XSS, неправильне керування сесіями, небезпечне використання функцій, відомі уразливі бібліотеки тощо. Якщо код звертається до бази даних – перевір, чи використовуються параметризовані запити. Якщо є обробка введення – чи є належна валідація/екранізація.
Склади список знайдених уразливостей або ризикованих місць в коді. Для кожного пунтку вкажи рівень небезпеки (високий/середній/низький) та рекомендації, як виправити код.
Якщо код розбитий на кілька частин, проаналізуй їх у комплексі (враховуючи виклики функцій між собою). Намагайся не пропустити логічні уразливості (наприклад, відсутність перевірки прав доступу перед виконанням критичної операції).”*

(Далі потрібно вставити фрагмент коду або кілька файлів по черзі, щоб модель могла їх проаналізувати. Варто подавати код частинами, якщо він великий, зберігаючи контекст розмови.)

За допомогою цього промпту ChatGPT (GPT-4) або Claude детально перевірять ваш код. Моделі знають багато поширених шаблонів уразливостей і навіть мають знання про відомі проблемні функції/API у різних мовах. Відомо, що GPT-4 часто успішно знаходить логічні помилки та частину вразливостей у коді, хоча може також повідомляти про сумнівні місця, що не обов’язково є багамиmixbytes.io. Тому отриманий звіт варто сприймати як первинний аудит: список підозрілих місць, які потребують додаткової перевірки. Перевага такого підходу – швидкість і широке охоплення: LLM може за хвилини пробігтися по тисячах рядків коду і сформувати перелік проблем, на який безпековому інженеру знадобилися б дні роботи.

3. Промпт для перевірки репутації та походження сайту (опціонально)

Іноді в рамках аудиту потрібно з’ясувати походження домену та репутацію сайту (чи не внесений він у чорні списки, кому належить, де розміщений). Хоча LLM не має прямого доступу до інструментів WHOIS або баз даних репутації без плагінів, можна спробувати отримати загальні відомості або інтерпретувати наявні дані. Наприклад:

“Перевір також інформацію про домен [URL сайту]: з’ясуй, на якому хостингу або в якій країні він розміщений (якщо відомо), коли приблизно створений (дати реєстрації домену), і чи немає ознак, що цей сайт може бути зловмисним (наприклад, дуже молодий домен, підозріла назва, відсутність SSL). Якщо знайдеш такі дані у відкритих джерелах – наведи їх у звіті в розділі ‘Походження та репутація сайту’. Врахуй, що без спеціальних інструментів інформація може бути обмеженою, тому дай оцінку на основі доступних фактів (наприклад, “домен зареєстровано нещодавно, що для великого інтернет-магазину незвично і може викликати підозри”).”

Цей запит можна додати до основного промпту аудиту. Він спонукає модель використати будь-які доступні їй знання (можливо, з попередніх веб-даних, якщо модель тренувалася на них) щодо домену. Звісно, для точної перевірки репутації краще скористатися окремими інструментами (VirusTotal, Google Safe Browsing тощо), але LLM може принаймні нагадати про ці аспекти і включити їх до звіту. Gemini від Google, імовірно, матиме глибшу інтеграцію з пошуковими даними, тож такий запит в Gemini може одразу дати актуальну інформацію про домен з інтернету.

Універсальний промпт для комплексного аудиту веб-сайту

Спираючись на вищенаведені приклади, можна скласти універсальний промпт, який об’єднує усі необхідні перевірки. Нижче представлено такий інтегрований шаблон. Він досить довгий, проте максимально самодостатній – потрібно лише вказати URL вашого сайту, і LLM (за умови наявності у неї потрібних інструментів або даних) спробує виконати решту автоматично:

Виступай як **висококваліфікований експерт з кібербезпеки**, нагороджений в галузі за видатні заслуги. Твоє завдання – провести **комплексний аудит безпеки веб-сайту** **[URL сайту]**. 

Виконай такі кроки:
1. **Збір інформації (Recon):** Визнач технології, що використовуються на сайті (CMS/Платформа, мова програмування бекенду, фреймворки, версії серверного ПЗ, бібліотеки на фронтенді). Зверни увагу на банери сервера, HTML-код головної сторінки, файли на кшталт `robots.txt`, щоб дізнатися про структуру сайту.
2. **Повне сканування сторінок:** Проскануй всі доступні сторінки та функції сайту. Для кожної знайди **точки введення даних** (форми, поля пошуку, URL-параметри). Перевір типові уразливості: 
   - **SQL Injection:** чи можна вставити спеціальні символи в параметри або форми і отримати помилку БД.
   - **XSS (міжсайтовий скриптінг):** чи фільтруються введені користувачем дані, перевір наявність захисту (наприклад, введи `<script>` і подивись, чи не відображається воно як код).
   - **CSRF:** чи є критичні дії без належних токенів захисту.
   - **Витік інформації:** перевір, чи не містять сторінки конфіденційних даних (стек-трейси, файли резервних копій, відкриті каталоги).
   - **Безпека автентифікації:** чи безпечна форма логіну (наприклад, чи є обмеження на кількість спроб, чи використовує HTTPS).
3. **Пошук адмін-інтерфейсів:** Спробуй виявити панелі адміністратора або сторінки входу. Перевір стандартні шляхи (`/admin`, `/administrator`, `/login`, `/wp-login.php` тощо) на відповіді. Якщо знайдеш – оціни, чи захищені вони (наприклад, чи є двофакторна автентифікація, капча, обмеження IP).
4. **Аналіз конфігурації та заголовків:** Перевір HTTP-заголовки безпеки: `Strict-Transport-Security`, `Content-Security-Policy`, `X-Frame-Options`, `X-Content-Type-Options`, `Referrer-Policy` тощо. Якщо якихось не вистачає або вони налаштовані неправильно – відзнач це. Переглянь сертифікат SSL (термін дії, валідність) та алгоритми шифрування. 
5. **Перевірка репутації та походження:** Визнач, кому належить домен (якщо ця інформація доступна), та географічне розташування сервера. Зверни увагу на вік домену і наявність сертифікатів безпеки. Повідом, чи виглядає сайт легітимним, чи не помічено його у відомих витоках/чорних списках (лише якщо тобі відомо).
6. **Оцінка коду (якщо код надано):** Якщо я надам фрагменти коду сайту – проаналізуй їх на вразливості (SQL-ін’єкції, XSS, неправильні налаштування безпеки). Враховуй знайдені проблеми коду в загальній оцінці.
7. **Звіт та рекомендації:** Сформуй детальний **звіт аудиту безпеки**. Він має включати:
   - **Короткий огляд (Executive Summary):** кілька речень про загальний стан безпеки сайту і основні знайдені проблеми.
   - **Таблицю або список знайдених вразливостей:** для кожної – назва/тип (наприклад, "SQL-ін’єкція в формі пошуку"), місце знайдення (URL або модуль), рівень ризику (низький/середній/високий) та опис впливу (що може статися при експлуатації).
   - **Оцінку безпечності на 10-бальній шкалі:** число від 1 до 10, підкріплене поясненням чому саме така оцінка (зважаючи на кількість вразливостей, їх критичність, наявність чи відсутність базових захисних механізмів).
   - **Рекомендації щодо усунення:** для *кожної* вразливості дай конкретні кроки, як її виправити. Наприклад: "оновити версію бібліотеки X до останньої, оскільки поточна версія уразлива до CVE-XXXX-YYYY", "впровадити валідацію користувацького вводу в скрипті Z", "заборонити доступ до /admin з мережі Інтернет або захистити його паролем". Також включи загальні покращення (якщо доречно) – наприклад, "впровадити WAF", "увімкнути двофакторну автентифікацію", "регулярно проводити пен-тести".
   - *Додатково:* якщо були перевірені репутаційні фактори або код – додай секцію про це (наприклад, "Походження сайту" чи "Результати аналізу коду"). 

**Важливо:** надавай відповідь у форматі, готовому до перетворення на PDF: використовуй заголовки, підзаголовки, марковані списки для переліку вразливостей та кроків. Стеж за чіткістю та професійним тоном викладу, ніби це офіційний звіт від консалтингової компанії з кібербезпеки.

Цей універсальний промпт поєднує елементи всіх попередніх. Він досить великий, проте завдяки цьому охоплює практично всі аспекти перевірки веб-сайту: від інфраструктури і конфігурації до прикладного рівня та вихідного коду. Подібний рівень деталізації відповідає реальному процесу аудиту, де безпековий спеціаліст:

Спочатку дізнається, на чому працює сайт, які версії ПЗ, щоб співставити їх з відомими уразливостями.
Потім перевіряє OWASP Top 10: SQLi, XSS, CSRF, вразливий контроль доступу, неправильну конфігурацію безпеки тощо.
Обов’язково аналізує наявність адмінок і відкритих девелоперських інтерфейсів (часто забудькуватістю залишають, наприклад, /admin.php без захисту або з паролем за замовчуванням).
Далі дивиться на налаштування протоколів і заголовків – це “низько висячі плоди” безпеки, які легко виправити, але багато сайтів про них забувають.
Опціонально враховує фактори довіри (репутація, домен, SSL) – це особливо актуально, якщо аудит виконується для, скажімо, фінансового сервісу, якому важливо мати бездоганний імідж у плані безпеки.
Якщо код доступний – проводить статичний аналіз коду (як людина вручну, так і модель може це робити). GPT-4/Claude можуть читати код і знаходити уразливості, але, як згадувалося, вони можуть як пропустити складну логічну помилку, так і “вигадати” проблему там, де її немаmixbytes.io. Тому результати слід перевіряти.

Використання промпту: Ви можете скопіювати цей промпт у вибрану LLM. Рекомендується застосовувати GPT-4 або аналогічну модель найвищого класу, оскільки обсяг завдання великий і вимагає складного багатокрокового аналізу. Якщо модель підтримує завантаження веб-сторінок (наприклад, через браузинг), вона сама відвідає сайт і збере HTML. Якщо ні – можливо, доведеться вручну надати вхідні дані (наприклад, результати сканування або тексти сторінок). В будь-якому разі, модель згенерує структурований звіт, який ви зможете відредагувати й оформити у PDF. Практика показує, що звіти, згенеровані ШІ, добре підходять як чернетка: вони економлять час на складання документу, охоплюючи всі основні моменти, а вам залишається тільки перевірити факти і додати специфічні деталі.

LLM для аудиту безпеки: як тестувати веб‑сайти за допомогою штучного інтелекту

Приклади промптів для аудиту безпеки сайту

1. Промпт для автоматизованого сканування веб-сайту на вразливості

2. Промпт для перевірки вихідного коду веб-додатку

3. Промпт для перевірки репутації та походження сайту (опціонально)

Універсальний промпт для комплексного аудиту веб-сайту

Рекомендації та застереження

Published by

Serhii Kholin