Здравствуйте, дорогие друзья.

Продолжаем рассматривать тематику написания хорошего отчета, и это 4 шаг.

Шаг 4: Дайте четкие шаги для воспроизведения

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

1. Войдите на сайт и перейдите по ссылке https://example.com/change_password.

2. Нажмите кнопку «Изменить пароль».

3. Перехватываем запрос, и меняем параметр user_id на другой идентификатор пользователя.

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

А теперь пример из лучшего отчета:

1. Создайте две учетные записи на сайте example.com: учетную запись A и учетную запись B.

2. Войдите на сайт example.com под учетной записью A и перейдите на https://example.com/, для изменения пароля.

3. Введите желаемый новый пароль в поле Новый пароль, расположенный по адресу в левом верхнем углу страницы.

4. Нажмите кнопку «Изменить пароль», расположенную в правом верхнем углу страницы.

5. Перехватите POST-запрос к https://example.com/change_password и измените параметр POST user_id на идентификатор пользователя учетной записи B.

6. Теперь Вы можете войти в учетную запись B, используя новый пароль, который Вы выбрали.

Хотя команда безопасности, вероятно, все же поймет первый отчет, второй отчет намного более конкретен. Предоставляя множество актуальных детали, Вы можете избежать недоразумений и ускорить устранение процесса.

Шаг 5: Предоставьте Proof of Concept

Для простых уязвимостей, описанных Вами, действия могут быть исчерпывающими, и команда должна воспроизвести проблему. Но для более сложных уязвимостей полезно включить видео, скриншоты или фотографии, документирующие Ваш эксплойт, и он называется файлом proof-of-concept (POC).

Например, для уязвимости CSRF вы можете включить файл HTML, со встроенной полезной нагрузкой CSRF. Таким образом, вся команда безопасности должна воспроизвести проблему, где нужно открыть HTML-файл в своем браузере. Для атаки с внешним объектом XML, включая созданный XML-файл, который Вы использовали для выполнения атаки. А для уязвимостей, требующих множественных сложных шагов, чтобы воспроизвести, Вы могли бы снять видео с экрана, на котором Вы идете через процесс.

Подобные POC-файлы экономят время службы безопасности, потому что они не будут самостоятельно готовить полезную нагрузку для атаки. Вы также можете включить любые созданные URL-адреса, сценарии или загружаемые файлы, которые Вы использовали для атаки на приложение.

Шаг 6: Опишите воздействие и сценарии атаки

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

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

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

Вот пример ударной секции:

Используя эту уязвимость, все, что нужно злоумышленнику для того, чтобы изменить пароль пользователя — это его user_id. Поскольку публичный доступ каждого пользователя на странице профиля указан как user_id учетной записи, любой может посетить страницу любого пользователя profile, узнать их user_id и изменить пароль. А также, поскольку user_id — это просто последовательные числа, хакер может даже перечислить все user_ids и изменить пароли всех пользователей! Эта ошибка позволит злоумышленникам завладеть чьей-либо учетной записью с минимальными усилиями.

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

Шаг 7: порекомендуйте возможные меры по смягчению последствий

Вы также можете порекомендовать возможные шаги, которые команда безопасности может предпринять, чтобы смягчить уязвимость. Это сэкономит время команде, когда она начнет исследования смягчения последствий. Часто, поскольку Вы являетесь исследователем безопасности, обнаружившим уязвимость, Вы будете знакомы с конкретным поведением этого приложения, и, таким образом, будете в хорошей позиции, чтобы придумать комплексное исправление.

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

Вот возможное смягчение, которое Вы могли бы предложить:

Приложение должно проверять параметр user_id пользователя. В запросе на смену пароля, чтобы убедиться, что пользователь имеет право вносить изменения в учетную запись. Неавторизованные запросы должны быть отклонены и зарегистрированы приложением.

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

Шаг 8. Подтвердите отчет

Наконец, всегда проверяйте свой отчет. Просмотрите свой отчет в последний раз, чтобы убедиться в том, что нет технических ошибок или чего-либо, что может помешать команде безопасности понять его. Следуйте собственным шагам, которые воспроизведите, чтобы убедиться, что они содержат достаточно деталей. Изучите все свои POC-файлы и код, удостоверившись в их работоспособности. Проверяя свои отчеты, Вы может свести к минимуму возможность отправки недействительного отчета.

Дополнительные советы по написанию более качественных отчетов

Вот дополнительные советы, которые помогут Вам создавать наилучшие отчеты.

Ничего не предполагай

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

Будьте ясны и лаконичны

С другой стороны, не включайте ненужную информацию, такую как словесные приветствия, шутки или мемы. Отчет о безопасности — это деловой документ, и не письмо к Вашему другу. Это должно быть прямо и по делу.

Сделайте свой отчет как можно короче, не опуская ключевых деталей. Вы всегда должны пытаться сэкономить время команды безопасности, чтобы они могли добраться, и немедленно устранить уязвимость.

Пишите то, что хотите прочитать

Всегда помните о своем читателе, когда пишете, и старайтесь создать хорошее чтение, и опыт для них. Пишите разговорным тоном и не используйте, сленг или сокращения. Это затрудняет чтение текста и добавит раздражение Вашего читателя.

Будьте профессионалом

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

На этом все. Всем хорошего дня!

#1 Bug Bounty — Руководство по поиску веб-уязвимостей и сообщениям о них. Введение.

#2 Bug Bounty. Выбор программы Bug Bounty.

#3 Bug Bounty. Типы активов в Bug Bounty.

#4 Bug Bounty. Платформы Bug Bounty.

#5 Bug Bounty. Скоуп, выплаты и время отклика.

#6 Bug Bounty. Частные программы.

#7 Bug Bounty. Написание хорошего отчета. Часть 1.