Как написать хороший отчёт о пентесте

#Что такое отчёт о тестировании на проникновение

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

NIST SP 800-115, техническое руководство по тестированию и оценке информационной безопасности, описывает весь процесс, включая анализ находок и разработку стратегий снижения риска. В OWASP Web Security Testing Guide есть глава Reporting, которая начинается со структуры отчёта и схемы именования находок. По возможности прочитайте оба документа. Здесь речь о том, что вы напишете первым: понятный отчёт с одной находкой, которую сможет воспроизвести другой человек.

#Зачем нужен отчёт

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

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

#Разделы отчёта

Практичная структура состоит из шести частей:

• Краткое резюме для руководства. Одна-две страницы для тех, кто остальное читать не будет. Здесь сказано, что тестировали, каков общий риск, какие находки важнее всего (простым языком) и что делать в первую очередь. Пишите это резюме последним, хотя стоит оно первым.
• Скоуп и разрешение. Хосты, URL и аккаунты, входившие в скоуп, что было исключено, даты тестирования, кто разрешил работу и какие действовали ограничения, например запрет на тестирование отказа в обслуживании.
• Методология. Подход и инструменты с версиями, настолько подробно, чтобы работу можно было повторить. Укажите, какие проверки выполнялись вручную.
• Находки. Одна запись на проблему, по убыванию серьёзности. Для всех записей один шаблон.
• Устранение. Исправления, сгруппированные по владельцу или теме, с приоритетами. У каждого исправления есть проверка, которая показывает, что оно работает.
• Приложение. Сырые улики без секретов, полные записи запросов и ответов и глоссарий для терминов, которых аудитория может не знать.

#Как написать одну находку

Каждая находка отвечает на одни и те же вопросы в одном и том же порядке.

• Заголовок. Что за изъян и где он находится. «Отражённый межсайтовый скриптинг в параметре search» сообщает читателю больше, чем «уязвимость XSS». В статье о межсайтовом скриптинге объяснён класс изъянов, стоящий за этим примером.
• Затронутый актив. Точный URL, эндпоинт, параметр, компонент или версия.
• Шаги воспроизведения. Пронумерованные шаги, которые посторонний человек сможет выполнить из чистой сессии браузера. Если шаг зависит от конкретного запроса, приведите этот запрос.
• Улики. Доказательство, что шаги сработали: скриншот или вывод curl -i без секретов. Нумеруйте каждую улику, чтобы на неё можно было сослаться из шагов.
• Импакт. Что атакующий может сделать в условиях, которые вы проверили.
• Серьёзность. Вектор CVSS v4.0 и его рейтинг, рассчитанные по тому, что вы проверили.
• Устранение. Конкретное исправление и проверка, которая показывает, что оно работает.

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

#Как описывать импакт без преувеличений

Импакт следует за уликами. Если вы показали, что скрипт выполнился в браузере тестового аккаунта в вашей лаборатории, так и пишите. Фраза вроде «атакующий может захватить любой аккаунт» без демонстрации будет преувеличением, и разработчик это заметит. К следующей находке доверия тоже станет меньше. Если вы что-то не проверяли, скажите об этом и назовите тест, который это подтвердил бы.

#Вывод сканера ещё не находка

Результат сканера подсказывает, куда смотреть. Прежде чем вносить его в отчёт, воспроизведите его вручную, запишите запрос и ответ и убедитесь в поведении сами. Сканер можно назвать источником зацепки. Сырой вывод как доказательство не вставляйте. Он может быть ошибочным, и читатель не поймёт, какие части кто-то проверил.

#Оценка серьёзности по CVSS v4.0

Спецификация CVSS v4.0 определяет группу метрик Base из двух частей. Метрики эксплуатируемости: attack vector (AV), attack complexity (AC), attack requirements (AT), privileges required (PR) и user interaction (UI). Метрики импакта относятся к уязвимой системе (VC, VI, VA) и последующим системам (SC, SI, SA). Строка вектора начинается с CVSS:4.0 и перечисляет все базовые метрики.

Качественные уровни серьёзности: None при 0.0, Low от 0.1 до 3.9, Medium от 4.0 до 6.9, High от 7.0 до 8.9 и Critical от 9.0 до 10.0.

Оценки бывают четырёх видов в зависимости от использованных групп метрик: CVSS-B только для Base, CVSS-BT для Base и Threat, CVSS-BE для Base и Environmental, CVSS-BTE для всех трёх. В первом отчёте обычно стоит базовая оценка, поэтому помечайте её CVSS-B и не выдавайте за полную оценку риска.

Для построения вектора и получения оценки откройте официальный калькулятор https://www.first.org/cvss/calculator/4.0 и работайте в нём. Приводите в отчёте сам вектор вместе с числом, чтобы читатель видел, какие допущения вы сделали. Строка ниже показывает только формат. Это не оценка какой-либо находки в вашей лаборатории:

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N

Оценивайте то, что проверили. Если атака зависит от условия, которое вы не смогли воспроизвести, метрика должна это отражать.

#Удаляйте секреты перед передачей

В уликах часто встречаются сессионные cookies, bearer-токены, пароли и персональные данные. Уберите их, прежде чем файл покинет вашу машину. Оставьте имя заголовка и форму значения, чтобы читатель мог разобраться в запросе:

Cookie: session=<REDACTED>
Authorization: Bearer <REDACTED>

Не вставляйте действующий токен в чат, тикет или публичный репозиторий и не коммитьте файл, где он ещё остался. Если секрет утёк в вашей собственной лаборатории, всё равно смените его там и отметьте смену в отчёте.

#Практика: одна находка из вашей лаборатории Juice Shop

Понадобится контейнер OWASP Juice Shop из вашей лаборатории, запущенный на вашей машине. Упражнение затрагивает только этот локальный экземпляр на 127.0.0.1. Не выполняйте эти шаги на сайтах, которые вам не принадлежат или на тестирование которых у вас нет письменного разрешения.

#1. Убедитесь, что лаборатория локальная

Выполните:

docker ps

Посмотрите на столбец с портами. Сопоставление должно начинаться с 127.0.0.1: это значит, что сервис доступен только с вашей машины. Если там 0.0.0.0 или адреса нет вообще, остановите контейнер и запустите его снова с адресом loopback во флаге публикации.

docker run -d -p 127.0.0.1:3000:3000 bkimminich/juice-shop

Затем проверьте, что лаборатория отвечает:

curl -i http://127.0.0.1:3000

В строке статуса должен быть код успешного ответа. Сохраните вывод. Он пойдёт в раздел о скоупе как доказательство того, какую цель вы тестировали.

#2. Выберите одну проблему, которую можете воспроизвести

Возьмите одно поведение, которое вы проверили в браузере или одним запросом и можете описать в несколько шагов. Держите скоуп небольшим. Одна хорошо подтверждённая находка полезнее восьми непроверенных.

#3. Соберите улики

Повторите запрос через curl -i, чтобы были видны заголовки. Подставьте путь из своей находки и сохраните вывод в файл:

curl -i "http://127.0.0.1:3000/<path-you-tested>" > evidence-01.txt

Флаг -i выводит заголовки ответа перед телом. Прочитайте строку статуса, заголовок Content-Type и любой заголовок, от которого зависит находка. Затем, перед коммитом, удалите из файла все токены и cookies.

#4. Заполните шаблон

Создайте report.md в репозитории лаборатории и используйте этот шаблон. Замените каждый заполнитель тем, что вы действительно наблюдали:

## Scope

- Target: http://127.0.0.1:3000, my own OWASP Juice Shop container
- Permission: I run this lab on a machine I own
- Dates: <start date> to <end date>
- Out of scope: everything else

## Finding title

<Flaw> in <exact location>

## Steps to reproduce

1. <Start from a clean browser session at http://127.0.0.1:3000>
2. <Exact action or request>
3. <What you see>

## Evidence

<Screenshot file name, or the redacted curl -i output file, matched to the steps>

## Impact

<What you verified. What you did not verify, and the test that would check it.>

## CVSS vector

<CVSS:4.0 vector from the calculator, and its rating>

## Remediation

<The specific fix, and how to check that it works>

#5. Закоммитьте отчёт

Перед коммитом проверьте, что запишет Git, чтобы туда не попал файл с неудалёнными секретами:

git add report.md
git status
git commit -m 'First lab finding'

Подтвердите коммит командой git log --oneline -1. В строке должно быть ваше сообщение. Когда закончите, остановите контейнер лаборатории командой docker stop <container-name>, затем запустите docker ps и убедитесь, что его больше нет в списке.

#Типичные ошибки

• Начинать с импакта. Сначала напишите шаги, потом решайте, что они доказывают.
• Шаги, зависящие от сессии, которой у читателя нет. Начинайте с чистого состояния и говорите об этом.
• Улики без связи с шагами. Нумеруйте улики и указывайте номер в каждом шаге.
• Вставлять вывод сканера как доказательство.
• Выбирать серьёзность на глаз. Используйте вектор и записывайте допущения, на которых он построен.
• Допускать утечку секретов в скриншоты, логи или коммиты.
• Исправление, которое нечем проверить.
• Описывать тест, который вы не запускали. В отчёте сказано, что произошло, по порядку.
• Отводить большую часть отчёта методологии. Самым большим разделом должны быть находки.

#Что дальше

• Прочитайте NIST SP 800-115 целиком. NIST распространяет публикацию бесплатно.
• Прочитайте главу Reporting в WSTG, начиная со структуры отчёта и схем именования.
• Прочитайте спецификацию CVSS v4.0, метрику за метрикой, прежде чем оценивать любую важную находку.
• Отдайте свою находку тому, кто её не писал, и попросите воспроизвести её только по шагам. Если не получится, находка не готова.
• Прочитайте правила проведения работ, прежде чем тестировать любую систему, которая вам не принадлежит. В статье о правилах bug bounty рассказано, как программы задают такие границы.

#Источники

• NIST SP 800-115, Technical Guide to Information Security Testing and Assessment
• OWASP Web Security Testing Guide, Reporting
• Penetration Testing Execution Standard, Reporting
• FIRST, CVSS v4.0 Specification Document
• FIRST, CVSS v4.0 Calculator