Отчёт по пентесту для начинающих: доказательства, риск, воспроизводимость и рекомендации по исправлению

Отчёт по пентесту — это не список уязвимостей, а документ, который помогает заказчику принять решение о выделении ресурсов на исправление. Хороший отчёт отвечает на три вопроса: что найдено, насколько это опасно и что конкретно делать. Если хотя бы один из вопросов остаётся без ответа, документ теряет практическую ценность.

Кому адресован отчёт и почему это важно​

У отчёта два основных читателя с разными потребностями:

• Техническая команда (разработчики, администраторы) — им нужны точные шаги воспроизведения, затронутые компоненты и конкретные патчи или конфигурационные изменения.
  
• Руководство и бизнес-заказчик — им нужен уровень риска в понятных терминах, влияние на бизнес-процессы и приоритизация исправлений.
  

Поэтому отчёт обычно содержит два слоя: executive summary для принятия решений и техническую часть для исполнения. Смешивать их в один поток — частая ошибка начинающих.

Структура отчёта: минимальный каркас​

Ниже — базовая структура, которая покрывает требования большинства заказчиков и соответствует рекомендациям NIST SP 800-115 по документированию результатов тестирования.

Раздел	Назначение	Объём
Executive Summary	Общая картина риска для руководства	1–2 страницы
Scope и методология	Что тестировалось, как и в каких рамках	0,5–1 страница
Находки (Findings)	Детальное описание каждой уязвимости	Основная часть
Рекомендации по исправлению	Конкретные действия для каждой находки	Входит в каждую находку или отдельный раздел
Приложения	Логи, скрины, сырые данные	По необходимости

Executive Summary: что писать и чего избегать​

Этот раздел читают люди, которые не будут погружаться в технические детали. Задача — дать картину риска за две минуты.

Что включить:

• Количество находок по уровням критичности (Critical, High, Medium, Low, Informational).
  
• Краткое описание наиболее серьёзных рисков и их потенциального влияния на бизнес.
  
• Общую оценку зрелости безопасности тестируемого объекта.
  
• Приоритетные действия на ближайшие 30/60/90 дней.
  

Чего избегать:

• Технического жаргона без пояснений.
  
• Перечисления всех находок подряд — это задача основного раздела.
  
• Оценочных суждений без опоры на данные («безопасность в ужасном состоянии»).
  

Scope и методология: фиксация границ​

Раздел фиксирует, что именно было в рамках теста и какие методы применялись. Это защищает обе стороны: пентестера — от претензий по поводу «не найденных» уязвимостей за пределами scope, заказчика — от неожиданностей.

Что указать:

• Целевые системы, IP-адреса, домены, приложения.
  
• Тип тестирования: black box, grey box, white box.
  
• Временные рамки и ограничения (например, запрет на DoS-тестирование).
  
• Инструменты и техники на высоком уровне.
  
• Ссылку на согласованный документ (Rules of Engagement, договор).
  

Анатомия одной находки​

Каждая уязвимость в отчёте описывается по единому шаблону. Это делает документ предсказуемым и упрощает работу разработчику, который будет исправлять проблему.

Заголовок и идентификатор​

Короткое название, отражающее суть: «SQL-инъекция в параметре id эндпоинта /api/products». Присвойте внутренний идентификатор (например, FINDING-001), чтобы на него можно было ссылаться в переписке.

Уровень критичности и оценка CVSS​

Уровень критичности (Critical / High / Medium / Low / Informational) определяется через CVSS-скоринг. Для начинающих важно понимать разницу между базовыми метриками:

Метрика	Что описывает	Примеры значений
Attack Vector (AV)	Как атакующий получает доступ	Network, Adjacent, Local, Physical
Attack Complexity (AC)	Насколько сложна эксплуатация	Low, High
Privileges Required (PR)	Нужны ли учётные данные	None, Low, High
User Interaction (UI)	Требуется ли действие жертвы	None, Required
Impact (C/I/A)	Влияние на конфиденциальность, целостность, доступность	None, Low, High

Не завышайте и не занижайте оценку. Если эксплуатация требует аутентификации администратора, это снижает Attack Vector и повышает Privileges Required — итоговый балл будет ниже, и это нормально.

Описание уязвимости​

Объясните корневую причину, а не только симптом. Разработчику важно понять, почему проблема возникла, чтобы исправить её системно, а не поставить заплатку.

Плохо: «Найдена XSS-уязвимость».
Хорошо: «Параметр search_query выводится в HTML-ответ без экранирования. Приложение не применяет контекстно-зависимое кодирование, что позволяет внедрить произвольный JavaScript в страницу результатов поиска».

Шаги воспроизведения (Proof of Concept)​

Это ключевой раздел для воспроизводимости. Разработчик или другой специалист по безопасности должен суметь повторить находку, следуя вашим инструкциям.

Требования к PoC:

• Каждый шаг нумерован и однозначен.
  
• Указаны конкретные URL, параметры, заголовки, payload.
  
• Приложены скриншоты или HTTP-запросы/ответы.
  
• Payload безопасен для данных: не удаляет записи, не шифрует файлы, не отправляет данные наружу.
  

Пример структуры PoC для XSS:

1. Открыть https://target.example.com/search
2. Ввести в поле поиска следующий payload:
   <script>alert(document.cookie)</script>
3. Нажать «Поиск».
4. Наблюдать: выполняется alert с содержимым cookie,
   что подтверждает отражённую XSS.

Если уязвимость требует аутентификации, укажите роль и минимальные привилегии, при которых она воспроизводится.

Затронутые компоненты​

Перечислите конкретные файлы, эндпоинты, версии библиотек или конфигурационные параметры. Чем точнее — тем быстрее разработчик найдёт нужное место в коде.

Влияние на бизнес (Impact)​

Опишите, что произойдёт при успешной эксплуатации, в терминах бизнеса: утечка данных клиентов, остановка сервиса, компрометация учётных записей, финансовый ущерб, репутационные потери. Это помогает руководству обосновать приоритет исправления.

Рекомендации по исправлению: конкретика вместо общих слов​

Рекомендация «исправьте XSS» бесполезна. Хорошая рекомендация содержит:

• Конкретное действие: применить контекстное экранирование при выводе пользовательского ввода в HTML.
  
• Ссылку на механизм или библиотеку: использовать Content-Security-Policy заголовок как дополнительный слой защиты.
  
• Приоритет: исправить в течение 7 дней для Critical, 30 дней для High.
  
• Способ проверки: после исправления повторить PoC и убедиться, что payload больше не исполняется.
  

Для разных классов уязвимостей рекомендации различаются:

Класс уязвимости	Пример конкретной рекомендации
SQL-инъекция	Использовать параметризованные запросы (prepared statements) вместо конкатенации строк
XSS	Применить контекстно-зависимое экранирование на этапе вывода; добавить CSP-заголовок
IDOR	Реализовать проверку прав доступа на сервере для каждого запрашиваемого ресурса
Устаревшее ПО	Обновить компонент до версии, в которой уязвимость исправлена; свериться с advisory вендора
Слабая конфигурация	Отключить ненужные сервисы, применить baseline-конфигурацию (CIS Benchmark)

Воспроизводимость: почему это критично​

Находка, которую невозможно воспроизвести, не является находкой — это гипотеза. Чтобы обеспечить воспроизводимость:

• Фиксируйте точную версию приложения, окружение, дату и время теста.
  
• Сохраняйте сырые HTTP-запросы (например, экспортом из прокси-инструмента).
  
• Если уязвимость зависит от состояния (гонка, кэш, сессия), опишите предусловия.
  
• Убедитесь, что PoC не зависит от ваших локальных настроек или специфичного состояния браузера.
  

Типичные ошибки начинающих​

Отсутствие приоритизации. Все находки помечены как High. Заказчик не понимает, за что браться в первую очередь. Используйте CVSS и бизнес-контекст для ранжирования.

Скриншоты без контекста. Скриншот алерта без указания, какой запрос его вызвал и на каком шаге, бесполезен для воспроизведения.

Копирование описаний из сканеров. Автоматические сканеры дают общее описание уязвимости, но не привязывают его к конкретному месту в приложении заказчика. Отчёт должен содержать привязку.

Рекомендации уровня «используйте безопасное кодирование». Это не действие. Разработчику нужно знать, какую функцию, библиотеку или паттерн применить в конкретном месте.

Отсутствие remediation verification. Укажите, как проверить, что исправление сработало. Без этого разработчик может закрыть тикет, не убедившись в результате.

Формат и оформление​

• Используйте единый шаблон для всех находок — это ускоряет чтение и поиск.
  
• Нумеруйте находки и давайте им короткие заголовки.
  
• Прикладывайте сырые данные (HTTP-запросы, логи) в приложение, а не в тело отчёта, чтобы не перегружать основной текст.
  
• Если отчёт содержит конфиденциальные данные (учётные записи, токены), передавайте его по защищённому каналу и согласуйте порядок хранения.
  

Чек-лист перед отправкой отчёта​

• [ ] Executive Summary понятен неспециалисту и содержит приоритизацию.
  
• [ ] Scope зафиксирован и совпадает с согласованным документом.
  
• [ ] Каждая находка содержит: заголовок, CVSS, описание, PoC, impact, рекомендацию.
  
• [ ] PoC воспроизводим другим специалистом без дополнительных вопросов.
  
• [ ] Рекомендации конкретны и содержат способ проверки исправления.
  
• [ ] Нет находок без привязки к конкретному компоненту или эндпоинту.
  
• [ ] Конфиденциальные данные не включены в отчёт в открытом виде без необходимости.
  
• [ ] Документ прошёл вычитку на предмет опечаток в URL, параметрах и payload.
  

Источники​

• SP 800-115, Technical Guide to Information Security Testing and Assessment | CSRC
  
• Web Security Academy: Free Online Training from PortSwigger