Web/API evidence pack: хороший finding должен переживать спор
Синтетический research-shot: схема проблемы, контроля, evidence и ретеста в фирменной лабораторной стилистике Virusologia.
Коротко: Evidence pack нужен не ради красоты PDF. Он нужен, чтобы разработчик, reviewer и руководитель видели одно и то же: что именно произошло, почему это риск и как доказать исправление.

Проблема

Во многих отчётах finding описан словами, но не переживает инженерный спор. Не хватает конкретного запроса, точного контекста роли, признака различия между expected и actual behavior, а иногда даже непонятно, это one-off artifact или воспроизводимый риск.

Когда evidence рыхлое, remediation замедляется: разработчики не уверены в проблеме, reviewer тратит время на перепроверку, а повторный запуск не знает, что сравнивать.

Решение

Для web/API finding полезно собирать компактный evidence pack: request, response status/body hash, role/state context, expected behavior, actual behavior, repro command и критерий исправления.

Хороший evidence pack умеет быть редактированным. Не нужно печатать секреты, cookies и PII, если можно сохранить контрольную сумму, безопасный фрагмент и стабильный technical marker.

Что проверить руками

  • Для каждого finding выделить minimal reproducible request.
  • Записать role/state context и бизнес-смысл различия.
  • Сохранить redacted body snippet или hash вместо лишних чувствительных данных.
  • Сформулировать retest так, чтобы он был бинарным и коротким.

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

  • Путать длинный raw dump с качественным evidence.
  • Не писать expected behavior и оставлять только 'так не должно быть'.
  • Оставлять retest в форме свободного комментария вместо проверяемого условия.

Defensive checklist

  • Есть minimal repro request.
  • Есть expected vs actual behavior.
  • Sensitive data отредактированы без потери проверяемости.
  • Retest можно выполнить быстро и однозначно.

Безопасный пример кода

JSON-скелет evidence pack для API finding. Пример рассчитан на owned/lab-среду и показывает инженерную логику проверки, а не эксплуатационную цепочку.

{
  "finding_id": "api-bola-01",
  "role": "viewer",
  "object_state": "submitted",
  "request": "GET /api/v1/orders/78231",
  "actual_status": 200,
  "expected_status": 403,
  "response_hash": "sha256:REPLACE_ME",
  "retest": "viewer must receive 403 for foreign submitted order"
}

Как это должно попасть в отчёт

  • Evidence pack вложен в finding, а не разбросан по приложению.
  • Reviewer может подтвердить finding без повторного исследования с нуля.
  • Ретест использует тот же пакет доказательства как baseline.
Этическая рамка: материал предназначен для defensive security, исследования собственных систем, controlled labs и подготовки remediation. Здесь нет вредоносных payload-цепочек, persistence-инструкций и шагов для несанкционированного доступа.