PENTEST.RED / REPORT
Пример отчёта о пентесте
Пример показывает, как один и тот же риск связывается с управленческим решением, инженерной задачей и проверяемым результатом. Опасные payload и рабочие секреты намеренно не приводятся.
Все организации, системы, события и выводы на этой странице вымышлены. Это демонстрация формата документа, а не заявление о проведённом проекте.
01 / DECISION
Управленческое резюме
В согласованном тестовом контуре вымышленного SaaS-продукта Example Workspace обнаружен один сценарий нарушения изоляции данных между организациями. Сценарий требовал действующей низкопривилегированной учётной записи и знания идентификатора тестового объекта. Разрушительных действий и доступа к реальным данным не выполнялось. Приоритет — исправить серверную проверку принадлежности объекта и проверить аналогичные операции.
Решения для владельца риска
- Назначить владельца исправления в API-команде.
- Проверить общий механизм объектной авторизации, а не только один маршрут.
- Не переносить выводы на непроверенные сервисы и окружения.
02 / BOUNDARIES
Контур и ограничения
Ниже указан пример того, как отчёт отделяет фактически проверенное от исключений. Реальный документ должен называть версии, даты, роли и тестовые окружения.
Проверено
- Тестовое Web-приложение и API v2.
- Две тестовые организации и роли Member / Manager.
- Чтение и изменение объектов проекта в согласованных сценариях.
Не проверено
- Production и данные реальных пользователей.
- Нагрузочное поведение и отказоустойчивость.
- Административная панель и сторонний файловый сервис.
03 / FINDING-001
Техническая находка
Недостаточная проверка принадлежности объекта при обновлении проекта
Пользователь одной тестовой организации мог обратиться к объекту другой организации через API. Сервер проверял наличие действующей сессии, но не подтверждал принадлежность объекта к организации пользователя для одной операции обновления.
Безопасное доказательство
В журнале тестового запроса зафиксирован код успешного ответа на изменение специально созданного маркерного поля тестового объекта. Идентификаторы, токены и содержимое ответа обезличены. В реальном проекте такие доказательства передаются в защищённом приложении к отчёту; на этой демонстрационной странице они не публикуются.
Наблюдаемое влияние
В пределах тестовых данных сценарий позволял изменить объект другой организации. Возможное влияние на другие типы объектов не заявляется: для такого вывода нужна отдельная проверка соответствующих маршрутов.
04 / REMEDIATION
План исправления
Исправление должно восстанавливать нарушенную границу доверия на сервере и покрывать общий класс операций.
- 01
Получать объект только в контексте организации из проверенной сервером сессии.
- 02
Применить общий middleware или policy для объектной авторизации ко всем операциям чтения и изменения.
- 03
Добавить негативные интеграционные тесты для разных организаций и ролей.
- 04
Логировать отклонённые межтенантные обращения без записи чувствительных значений.
05 / ACCEPTANCE
Ретест и приёмка
Ретест начинается после указания версии сборки, окружения и списка изменённых компонентов. Проверяется исходный сценарий и разумные обходы в том же классе контроля.
Критерии успешного ретеста
- Пользователь организации A не может читать или менять тестовые объекты организации B.
- Контроль действует для прямых API-вызовов и не зависит от ограничений интерфейса.
- Ожидаемый отказ стабилен для проверенных ролей и не раскрывает сведения о существовании объекта.
- Позитивные операции владельца объекта продолжают работать.
Исправлено — критерии выполнены в тестовой сборке 2.4.1. Production не проверялся. Этот статус является частью синтетического примера.
06 / LIMITS
Ограничения вывода
Пентест даёт вывод о согласованном контуре и периоде, а не гарантию отсутствия уязвимостей. Изменения после даты проверки, исключённые компоненты и недоступные роли требуют отдельной оценки.
PENTEST.RED
Примените этот формат к своему проекту
Сначала определите активы, роли, запрещённые действия и решения, которые должен поддержать отчёт.