Writing findings

Находка — единственный значимый артефакт

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

Поэтому находка — это единица работы, а не повод похвастаться. Зрелая дисциплина — писать каждую находку так, чтобы незнакомый человек взял её «с холода» и довёл до закрытия, не задав тебе ни единого вопроса.

Четыре части, нужные каждой находке

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

Воспроизведение — та часть, которую джуны пропускают, а зрелые ставят впереди, потому что именно она превращает заявление в факт. Инженер должен суметь повторить твои шаги и увидеть баг на своей машине: точный эндпоинт, два тестовых аккаунта и кто из них кто, любые предусловия (зашёл низкопривилегированным пользователем, конкретный id записи), точный отправленный запрос и — что критично — ожидаемое vs фактическое, чтобы нарушение было однозначным. «Аккаунт B запросил инвойс аккаунта A и получил его (ожидалось: 403)» не оставляет места для трактовки. Без этого первое, что делает заказчик, — не воспроизводит, а находку, которую никто не может воспроизвести, закрывают как won’t-fix, какой бы реальной она ни была.

Влияние отвечает на вопрос и что с того. Важность — это число; влияние — фраза, которая это число заслуживает. Ловушка — писать общее влияние («IDOR может привести к несанкционированному доступу к данным») вместо конкретного для этого приложения («любой аутентифицированный пользователь может прочитать инвойс любого другого — имя, адрес выставления счёта и последние цифры карты — инкрементируя одно целое число»). Конкретное влияние удерживает инженера от того, чтобы подшить баг как теоретический пентестерский шум; оно привязывает уязвимость к данным и ущербу, которые он узнаёт.

Важность — это сигнал приоритизации, и её задача — согласованность. Используй определённую шкалу — CVSS для каталогизированных CVE, качественный рейтинг вероятность × влияние для логических багов — и приложи однострочное обоснование, которое защитишь на разборе. Самый частый сбой здесь — инфляция важности: пометить всё как High, чтобы отчёт выглядел грозно. Это бьёт по тебе же — когда каждая находка High, заказчик не отличит SSRF к metadata-учёткам от отсутствующего security-заголовка, и твой настоящий критикал тонет. Откалиброванная важность — это то, что делает отчёт пригодным как очередь работ.

Исправление должно чинить корневую причину, а не симптом. «Санитизируй ввод» — канонический плохой фикс: это совет, а не изменение, и часто он латает не тот слой. Хорошее исправление называет конкретное изменение на уровне кода: для IDOR — ограничь запрос вызывающим (WHERE id = ? AND owner_id = ?, на сервере), а не «добавь валидацию». Исправление, которое инженер может вставить и адаптировать, стоит десяти абзацев предыстории.

Пишем для инженера, а не для хакера

Самый трудный сдвиг для сильного тестировщика — осознать, что отчёт это документ передачи, а получатель не разделяет твой контекст. Три привычки отделяют находку, которая закрывается, от той, что гниёт. Первое: пиши ожидаемое vs фактическое для каждого шага воспроизведения — это самая рычажная фраза, потому что она делает нарушение неоспоримым и самопроверяемым. Второе: не прячь главное — начинай с однострочного резюме (что + влияние + важность), затем детали, потому что инженер, сортирующий пятьдесят находок, читает первую строку каждой и распределяет бюджет от неё. Третье: сделай исправление вставляемым — укажи точный обработчик и точное изменение, и где можешь — сошлись на соответствующий контроль (например, тест WSTG, который ему сопоставлен), чтобы фикс был проверяемым.

Проработанная находка против голого ярлыка

Возьми IDOR из вступления. Плохая версия — одна строка: «High — IDOR на инвойсах.» Версия-находка звучит так: Резюме — любой аутентифицированный пользователь может прочитать инвойс любого другого, изменив id (High). Воспроизведение — войди тестовым аккаунтом B, отправь GET /api/invoices/{A_invoice_id} с сессией B, наблюдай 200 с инвойсом аккаунта A (имя, адрес выставления, последние цифры карты); ожидалось 403. Влияние — полный доступ на чтение к PII всех клиентов и части данных карты по всему тенанту, эксплуатируется любым залогиненным пользователем без особых прав. Важность — High: тривиально эксплуатируется (целое число правится в URL), ценные данные, широкий радиус поражения. Исправление — обеспечь владение на сервере по фактической записи: смени запрос на WHERE id = ? AND owner_id = ? (или эквивалентную проверку авторизации) на этом и на каждом обработчике объекта по id; запрет по умолчанию. Одна из них закрывается за день; другая — это мнение.