Ты можешь взломать всё, что движется, но если отчёт нечитаем — клиент не исправит ни одной уязвимости. Отчёт — это финальный и самый важный эксплойт в цепочке: эксплойт против непонимания менеджмента.
Технический навык взлома — только половина профессии пентестера. Вторая половина — умение объяснить находки так, чтобы бизнес их понял, приоритизировал и исправил. Плохой отчёт обесценивает даже гениальный пентест: клиент не читает 200 страниц сырых логов Burp Suite и просто откладывает документ в стол.
🎯 Кто читает отчёт — и почему это меняет всё
Главная ошибка новичков — писать один текст для всех. У отчёта минимум два читателя с противоположными потребностями:
| Аудитория | Что хочет знать | Язык |
|---|---|---|
| Топ-менеджмент, CISO | Насколько мы в опасности? Сколько денег на исправление? | Бизнес-язык, без жаргона |
| Технические специалисты | Как именно уязвимость работает? Как воспроизвести и исправить? | Технический, с PoC и кодом |
💡 Правило SANS Institute: отчёт должен работать как две отдельные книги в одной обложке — краткое резюме для директора и глубокая техническая часть для инженера.
🏗️ Структура отчёта: канонический скелет
Стандартная структура, принятая индустрией и используемая в большинстве компаний:
|
1 2 3 4 5 6 7 8 |
1. Титульный лист 2. Executive Summary (Краткое резюме для руководства) 3. Общие сведения о проекте 4. Методология тестирования 5. Оценка рисков (сводная таблица) 6. Детальное описание уязвимостей 7. Рекомендации и план действий 8. Приложения (сырые данные, скрипты, скриншоты) |
📄 Раздел 1: Титульный лист и общие сведения
Формальная часть, но она задаёт тон профессионализма:
|
1 2 3 4 5 6 7 8 9 10 11 |
## ОТЧЁТ О ТЕСТИРОВАНИИ НА ПРОНИКНОВЕНИЕ Заказчик: [Название компании] Исполнитель: [Название компании / ФИО] Период проведения работ: 15.06.2026 – 29.06.2026 Основание: Договор №___ от ___, Letter of Authorization Объект тестирования: Веб-приложение app.target.com, внутренняя сеть 192.168.1.0/24 Классификация документа: КОНФИДЕНЦИАЛЬНО Версия отчёта: 1.0 Дата составления: 30.06.2026 |
📊 Раздел 2: Executive Summary — самый важный абзац во всём документе
Директор читает только это. Три-пять предложений, ноль технического жаргона:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
## Краткое резюме В ходе тестирования на проникновение веб-приложения app.target.com было выявлено 14 уязвимостей: 2 критические, 4 высокие, 6 средних и 2 низкие. Наиболее опасная находка — возможность получения полного контроля над сервером через уязвимость загрузки файлов, что могло привести к утечке базы данных клиентов (2.3 млн записей) и остановке работы сервиса. Общий уровень защищённости системы оценивается как СРЕДНИЙ. Рекомендуется устранить критические уязвимости в течение 24 часов, высокие — в течение 7 дней. |
Что обязательно включить:
-
Цель тестирования (одно предложение)
-
Общее количество находок с разбивкой по критичности
-
Топ-3 самых опасных находки простым языком
-
Бизнес-последствия (деньги, репутация, утечка данных)
-
Общая оценка уровня защищённости
-
Призыв к действию — что делать в первую очередь
🔬 Раздел 3: Методология — показываем системность работы
Раздел объясняет, что именно делалось и по каким стандартам:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
## Методология Тестирование проводилось в соответствии с методологиями: - OWASP Testing Guide v4.2 - PTES (Penetration Testing Execution Standard) - NIST SP 800-115 Этапы работ: 1. Разведка (Reconnaissance) — OSINT, сбор данных о цели 2. Сканирование (Scanning) — Nmap, поиск сервисов и версий 3. Анализ уязвимостей (Vulnerability Analysis) — Burp Suite, ручной анализ логики приложения 4. Эксплуатация (Exploitation) — подтверждение уязвимостей рабочими PoC 5. Пост-эксплуатация (Post-Exploitation) — оценка глубины компрометации 6. Составление отчёта Инструменты: Nmap, Burp Suite Professional, sqlmap, Metasploit Framework, Nikto Ограничения: DoS-атаки не проводились по условиям scope. Социальная инженерия не входила в объём работ. |
💣 Методология доказывает клиенту: это не случайное «постучались и посмотрели», а системный процесс с чётким scope. Это прямо влияет на доверие к результатам.
🎨 Раздел 4: CVSS — как правильно оценивать критичность
CVSS (Common Vulnerability Scoring System) — индустриальный стандарт для количественной оценки серьёзности уязвимостей, версии 3.1 и 4.0 актуальны в 2026 году.
Как считается базовый score
CVSS складывается из метрик, объединённых в векторную строку:
|
1 2 3 4 5 6 7 8 9 10 |
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H AV (Attack Vector) — N: Network / A: Adjacent / L: Local / P: Physical AC (Attack Complexity) — L: Low / H: High PR (Privileges Required) — N: None / L: Low / H: High UI (User Interaction) — N: None / R: Required S (Scope) — U: Unchanged / C: Changed C (Confidentiality) — N: None / L: Low / H: High I (Integrity) — N: None / L: Low / H: High A (Availability) — N: None / L: Low / H: High |
Пример расчёта: SQL-инъекция без аутентификации, полный доступ к БД:
|
1 2 3 4 5 |
AV:N (доступна из сети) / AC:L (легко эксплуатировать) / PR:N (не нужны привилегии) / UI:N (без взаимодействия юзера) / C:H / I:H / A:H (полная компрометация данных) → CVSS Score: 9.8 (CRITICAL) |
Таблица классификации по CVSS
Стандартная шкала критичности, используемая большинством российских и международных отчётов:
| Уровень | CVSS Score | Срок устранения | Примеры |
|---|---|---|---|
| Критический 🔴 | 9.0 – 10.0 | 24 часа | RCE, полная компрометация системы |
| Высокий 🟠 | 7.0 – 8.9 | 7 дней | Privilege Escalation, SQL Injection |
| Средний 🟡 | 4.0 – 6.9 | 14 дней | XSS, CSRF, Information Disclosure |
| Низкий 🟢 | 0.1 – 3.9 | 30 дней | Слабые пароли, неполная конфигурация |
| Информационный ⚪ | 0.0 | По желанию | Best practice рекомендации |
|
1 2 3 4 5 6 |
# Онлайн-калькулятор для точного расчёта: # https://www.first.org/cvss/calculator/4.0 # В отчёте всегда указывай и score, и вектор: # CVSS Score: 9.8 (Critical) # Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H |
🐛 Раздел 5: Описание уязвимости — сердце технической части
Каждая находка должна следовать единому шаблону — это облегчает чтение и повторяемость:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 |
## Уязвимость #1: SQL Injection в форме поиска **CVSS Score:** 9.1 (Critical) **Vector:** CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L **Затронутый ресурс:** https://app.target.com/search?q= ### Описание Параметр `q` в эндпоинте поиска не проходит валидацию и позволяет внедрить произвольные SQL-запросы. Приложение использует конкатенацию строк вместо параметризованных запросов. ### Доказательство эксплуатации (Proof of Concept) **Запрос:** ```http GET /search?q=laptop' UNION SELECT username,password FROM users-- - HTTP/1.1 Host: app.target.com ``` **Ответ сервера:** ```json {"results": [{"username": "admin", "password": "5f4dcc3b5aa765d61d8327deb882cf99"}]} ``` *[Скриншот: перехват запроса в Burp Suite, показывающий утечку данных]* ### Последствия Атакующий может извлечь всю базу данных, включая учётные записи пользователей, платёжную информацию и персональные данные. При модификации запроса возможно изменение или удаление данных. ### Рекомендация по устранению Использовать параметризованные запросы (prepared statements) во всех обращениях к базе данных. Пример безопасного кода: ```python # Вместо: query = f"SELECT * FROM products WHERE name LIKE '%{search}%'" # Использовать: query = "SELECT * FROM products WHERE name LIKE %s" cursor.execute(query, (f"%{search}%",)) ``` Дополнительно: внедрить WAF-правила для фильтрации SQL-паттернов, провести аудит всех остальных SQL-запросов в приложении. **Ссылки:** CWE-89, OWASP Top 10 A03:2021 |
Обязательные элементы каждой находки:
|
1 2 3 4 5 6 7 8 |
✅ Название и уникальный ID уязвимости ✅ CVSS Score + вектор ✅ Затронутый актив (URL, IP, компонент) ✅ Описание технической причины ✅ Proof of Concept — воспроизводимые шаги + скриншоты ✅ Бизнес-последствия эксплуатации ✅ Конкретная рекомендация по исправлению (с кодом, если применимо) ✅ Ссылки на CWE / OWASP / CVE |
📈 Раздел 6: Оценка рисков — визуализация для быстрого понимания
Таблица и график критичности помогают бизнесу расставить приоритеты за секунды
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
## Сводная таблица находок | ID | Уязвимость | CVSS | Критичность | Статус | |----|-----------|------|-------------|--------| | V-01 | SQL Injection в поиске | 9.1 | Critical | Открыта | | V-02 | Unrestricted File Upload → RCE | 9.8 | Critical | Открыта | | V-03 | Broken Access Control (IDOR) | 8.2 | High | Открыта | | V-04 | Устаревший Apache 2.2.8 | 7.5 | High | Открыта | | V-05 | Reflected XSS в профиле | 6.1 | Medium | Открыта | | V-06 | Отсутствие rate limiting на /login | 5.3 | Medium | Открыта | | V-07 | Слабая политика паролей | 3.1 | Low | Открыта | Распределение по критичности: Critical: ██ 2 (14%) High: ████ 2 (14%) Medium: ██████ 6 (43%) Low: ████ 4 (29%) |
💡 Многие компании оформляют это как pie chart или bar chart — визуализация распределения критичности воспринимается в разы быстрее текста.
🛠️ Раздел 7: Рекомендации — план действий, а не список проблем
Клиент должен закрыть отчёт с чётким пониманием, что делать прямо сейчас:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
## Рекомендации по устранению ### Немедленно (0-24 часа) — Critical 1. Отключить эндпоинт /upload до внедрения валидации типов файлов 2. Внедрить параметризованные запросы во всех формах ввода 3. Изолировать production-БД от прямого доступа из приложения ### Краткосрочно (1-7 дней) — High 4. Обновить Apache до актуальной версии 2.4.6x 5. Внедрить проверку авторизации на уровне объектов (исправление IDOR) 6. Настроить WAF-правила для базовой фильтрации ### Среднесрочно (2-4 недели) — Medium/Low 7. Внедрить Content Security Policy для защиты от XSS 8. Настроить rate limiting на критичных эндпоинтах 9. Обновить политику паролей (минимум 12 символов, MFA) ### Организационные меры 10. Внедрить SAST/DAST в CI/CD pipeline 11. Проводить регулярные пентесты (минимум раз в год) 12. Обучить команду разработки безопасному кодированию |
✍️ Правила хорошего письма в пентест-отчёте
Три принципа, которые определяют, будет отчёт полезен или проигнорирован:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
1. ПИШИ ДЛЯ РАЗНЫХ АУДИТОРИЙ Executive Summary — простым языком. Технический раздел — точными терминами с PoC. 2. БУДЬ КОНКРЕТЕН ❌ "Обнаружены проблемы с безопасностью паролей" ✅ "Политика паролей допускает 4-значные PIN-коды, что позволяет взломать 73% учётных записей за 10 минут" 3. БУДЬ ОБЪЕКТИВЕН Фиксируй не только проблемы, но и сильные стороны системы. Это повышает доверие к отчёту как к профессиональному документу. 4. МИНИМУМ ЖАРГОНА В БИЗНЕС-ЧАСТИ ❌ "RCE позволяет выполнить произвольный код" ✅ "Уязвимость позволяет злоумышленнику запустить вредоносный код на сервере компании" 5. НАГЛЯДНОСТЬ ПОВЕРХ ТЕКСТА Таблицы, графики, скриншоты вместо сплошных абзацев. Сырые логи — в приложение, не в основной текст. 6. НИКАКИХ ОБВИНЕНИЙ Не "разработчики допустили критическую ошибку", а "выявлена уязвимость, требующая исправления". |
🔒 Обработка чувствительных данных в отчёте
Отчёт сам по себе — критичный актив. Утечка отчёта = утечка карты всех уязвимостей компании:
|
1 2 3 4 5 6 |
✅ Маркировка "КОНФИДЕНЦИАЛЬНО" на каждой странице ✅ Пароли и токены в PoC — маскировать частично: P@ssw*** ✅ Реальные персональные данные из БД — заменять на примеры ✅ Передача отчёта только через зашифрованные каналы ✅ Ограниченный срок хранения после проекта (согласно NDA) ✅ Отдельная версия отчёта без критичных деталей для широкой аудитории |
📋 Финальный чеклист перед отправкой клиенту
|
1 2 3 4 5 6 7 8 9 10 11 |
✅ Executive Summary написан без технического жаргона ✅ Каждая находка имеет CVSS score и вектор ✅ Каждая находка содержит воспроизводимый PoC ✅ Каждая находка содержит конкретную рекомендацию ✅ Есть сводная таблица/график критичности ✅ Рекомендации приоритизированы по срокам ✅ Орфография и структура проверены ✅ Отчёт прочитан коллегой на предмет понятности ✅ Чувствительные данные замаскированы или вынесены в приложение ✅ Документ помечен как конфиденциальный ✅ Клиент после чтения понимает: что исправлять и в каком порядке |
💣 Итог: хороший пентест без хорошего отчёта — деньги, потраченные впустую для клиента. CVSS даёт объективность, структура даёт ясность, конкретные рекомендации превращают находки в исправленный код. Отчёт — это последний и самый недооценённый скилл в карьере пентестера, и именно он определяет, вернётся ли клиент к тебе снова.
