Отчёт

Один документ. Два читателя.

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

Читатели
Руководство
и инженеры
Перепроверка
Добавляется
в тот же отчёт
Формат
Цифровой или печатный
в нужном вам формате
Передача
Цифровые копии
шифруются вашим публичным ключом

Шесть частей, всегда в одном порядке.

  1. 01

    Резюме для руководства

    Что тестировали, что нашли и что это значит для бизнеса — простым языком, на одной странице.

  2. 02

    Скоуп и методология

    Какие именно цели входили в скоуп, когда проводилось тестирование и как.

  3. 03

    Сводка находок

    Все находки в одной таблице, с оценкой реального бизнес-риска и текущим статусом.

  4. 04

    Подробные находки

    Для каждой: описание, влияние, доказательства, шаги воспроизведения и конкретное исправление.

  5. 05

    План исправлений

    Что исправить сейчас, что может подождать и что может быть приемлемым риском.

  6. 06

    Результаты перепроверки

    После исправлений каждая находка проверяется снова, а результат добавляется в тот же отчёт.

Что руководство читает первым.

Пример / не данные клиента

При тестировании клиентской платформы найдена одна критическая проблема: любой вошедший пользователь мог читать заказы всех остальных клиентов. Она и проблема высокого риска со сбросом пароля исправлены и подтверждены перепроверкой. Одна проблема среднего уровня в работе; одна низкого уровня принята как риск.

Критический
1
Высокий
1
Средний
1
Низкий
1
Отчёт о тестировании на проникновение
Пример / не данные клиента
Сводка находок — пример
ID / НаходкаРискСтатус
F-01Любой пользователь может читать чужие заказы через APIКритическийИсправлено · перепроверено
F-02Ссылка для сброса пароля действует после использованияВысокийИсправлено · перепроверено
F-03Нет ограничения числа попыток входаСреднийВ работе
F-04Страницы ошибок раскрывают внутренний stack traceНизкийРиск принят

Что инженеры получают по каждой находке.

F-01 · Пример

Любой пользователь может читать чужие заказы через API

Риск
Критический
Затронуто
GET /api/orders/{id}
Статус
Исправлено

Описание

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

Влияние

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

Доказательство

GET /api/orders/10482 HTTP/1.1
Host: shop.example.com
Authorization: Bearer <token of user B>
HTTP/1.1 200 OK
Content-Type: application/json

{ "id": 10482, "customer": "user A", "address": "[redacted]", "items": [ … ] }

Воспроизведение

  1. Войдите как пользователь A и оформите заказ; запишите его ID.
  2. В отдельной сессии войдите как пользователь B.
  3. Запросите ID заказа пользователя A с токеном пользователя B.
  4. API возвращает заказ пользователя A вместо 403 Forbidden.

Исправление

Проверяйте владельца на сервере при каждом запросе объекта: загружайте заказ, только если его владелец совпадает с аутентифицированным пользователем, иначе возвращайте 404. Примените ту же проверку ко всем эндпоинтам, принимающим ID объекта.

Перепроверка

Исправлено · перепроверено. Теперь эндпоинт возвращает 404 для заказов другого пользователя.

Что исправлять и в каком порядке.

  1. 01

    Исправить сейчас

    • F-01Любой пользователь может читать чужие заказы через API
    • F-02Ссылка для сброса пароля действует после использования
  2. 02

    Исправить следом

    • F-03Нет ограничения числа попыток входа
  3. 03

    Решить

    • F-04Страницы ошибок раскрывают внутренний stack trace