#7 Bug Bounty. Написание хорошего отчета. Часть 1.
Здравствуйте, дорогие друзья.
Поддерживание Вашего успеха в охоте
Даже если Вы понимаете техническую информацию, в этом разделе у Вас могут возникнуть трудности ориентирования в нюансах программ вознаграждения за обнаружение ошибок. Или Вы, возможно, изо всех сил пытаетесь найти законные ошибки и не знаете, почему застряли на каком-либо этапе. В этом разделе мы рассмотрим некоторые факторы, которые формируют успешного багхантера. Что ж осветим, как написать отчет, который правильно описывает свои выводы команде безопасности, чтобы построить прочные отношения с организациями, с которыми Вы работаете, и преодолевайте препятствия во время поиска багов.
Написание хорошего отчета
Работа багхантера заключается не только в поиске уязвимостей; но, также, происходит в объяснении их службе безопасности организации. Если Вы предоставите хорошо написанный отчет, Вы поможете команде, с которой Вы работаете, воспроизвести эксплойт, назначить его соответствующую внутреннюю команду инженеров и решить проблему быстрее. Чем быстрее уязвимость будет устранена, тем меньше вероятность того, что злоумышленники воспользуются ею. В этом разделе я разберу компоненты хорошего отчета об уязвимостях, и познакомлю Вас с некоторыми советами и приемами, которые я изучил на этом пути.
Шаг 1: Создайте описательный заголовок
Первая часть хорошего отчета об уязвимостях всегда носит описательный заголовок. Укажите цель для названия, которое резюмирует проблему в одном предложении. В идеале он должен позволять службе безопасности, сразу получить представление о том, что это за уязвимость, где она произошла, и ее потенциальную тяжесть. Для этого он должен ответить на следующие вопросы: Какую уязвимость Вы нашли? Это пример известного типа уязвимости, такую как IDOR или XSS? Где Вы его нашли в целевом приложении?
Например, вместо заголовка отчета «IDOR на критической конечной точке» используйте такой, как «IDOR на https://example.com/change_password ведет к учетной записи поглощения для всех пользователей». Ваша цель — дать инженеру по безопасности чтение Вашего отчета, и это дает хорошее представление о содержании, которое Вы будете обсуждать в остальной части.
Шаг 2: Предоставьте четкое резюме
Далее предоставьте сводку отчета. В этом разделе содержится вся необходимая информация, и Вы не смогли описать все в заголовке, как и параметры HTTP-запроса, используемый для атаки, как Вы его нашли и так далее.
Вот пример эффективной сводки отчета:
Конечная точка https://example.com/change_password принимает два запроса POST, параметра body: user_id и new_password. POST-запрос к этой конечной точке изменит пароль пользователя user_id на новом пароле. Эта конечная точка не проверяет параметр user_id, и в результате любой пользователь может сменить чужой пароль, манипулируя параметром user_id.
Резюме хорошего отчета должно быть четким и кратким. В нем содержится вся информация, которое дает понимание уязвимости, в том числе, что это за ошибка, где обнаружена ошибка и что может сделать злоумышленник, когда она будет использована.
Шаг 3. Включите оценку серьезности
Ваш отчет также должен включать честную оценку серьезности ошибки. Помимо работы с Вами, над устранением уязвимостей, группы безопасности выполняют другие обязанности, к которым нужно стремиться. Включение оценки серьезности поможет расставить приоритеты, какие уязвимости нужно исправить в первую очередь, и гарантируют, чтобы сразу же позаботиться о критических уязвимостях.
Вы можете использовать следующую шкалу для сообщения серьезности:
Низкая серьезность
Ошибка не может нанести большой ущерб. Например, открытое перенаправление, которое можно использовать только для фишинга, является ошибкой с низким уровнем серьезности.
Средняя серьезность
Ошибка оказывает умеренное влияние на пользователей или организацию, либо это проблема высокой степени серьезности, которую злоумышленнику сложно использовать. Команда безопасности должна в первую очередь сосредоточиться на ошибках высокой и критической важности. Например, подделка межсайтовых запросов (CSRF) для конфиденциального действия, такого как, изменение пароля, часто считается проблемой средней степени серьезности.
Высокая серьезность
Ошибка затрагивает большое количество пользователей, и ее последствия могут быть катастрофическими для этих пользователей. Команда безопасности должна исправить ошибку как можно скорее. Например, открытая переадресация, которую можно использовать в краже токенов OAuth — это ошибка высокой степени серьезности.
Критическая серьезность
Ошибка затрагивает большую часть пользовательской базы или ставит под угрозу деятельность основной инфраструктуры организации. Команда безопасности должна исправить критическую ошибку сразу. Например, SQL-инъекция, ведущая к удаленному коду выполнение (RCE) на производственном сервере будет считаться критической проблемой.
Изучите общую систему оценки уязвимостей (CVSS) на странице https://www.first.org/cvss/, чтобы получить общее представление о том, насколько критичен каждый тип уязвимости.
Шкала CVSS учитывает такие факторы, как влияние уязвимости на организации, насколько сложно эксплуатировать уязвимость и требует ли уязвимость каких-либо специальных привилегий или взаимодействия с пользователем для использования.
Затем попытайтесь представить, что заботит вашу компанию-клиента, и что уязвимости окажут наибольшее влияние на бизнес. Настройте свою оценку в соответствии с бизнес-приоритетами клиента. Например, сайт знакомств.
Можно найти ошибку, которая выставляет дату рождения пользователя как несущественную, поскольку возраст пользователя уже является общедоступной информацией на сайте, а сайт поиска работы может счесть подобную ошибку существенной, потому что возраст заявителя должен быть конфиденциальным в процессе поиска работы. С другой стороны, утечки информации о пользователях банковской информации почти всегда считается проблемой высокой степени серьезности.
Если Вы не уверены, к какому уровню серьезности относится ваша ошибка, используйте рейтинг платформы Bug Bounty. Например, рейтинговая система Bugcrowd учитывает тип уязвимости и затронутую функциональность (https://bugcrowd.com/vulnerability-rating-taxonomy/), а HackerOne предоставляет калькулятор серьезности на основе шкалы CVSS (https://docs.hackerone.com/hackers/severity.html).
Вы можете указать серьезность в одной строке следующим образом:
Серьезность проблемы: Высокая
На этом все. Всем хорошего дня!
#1 Bug Bounty — Руководство по поиску веб-уязвимостей и сообщениям о них. Введение.
#2 Bug Bounty. Выбор программы Bug Bounty.
#3 Bug Bounty. Типы активов в Bug Bounty.
#4 Bug Bounty. Платформы Bug Bounty.