Отчёты об уязвимостях

Итак, наконец-то пришел тот день, и вы нашли свою первую уязвимость. Во-первых, поздравляю! Серьезно, найти уязвимые места нелегко, но не стоит сбавлять обороты.

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

Я хочу помочь вам избежать этого. Поэтому, сначала самое главное.

Прочитайте рекомендации по раскрытию информации.

Если вы находитесь на HackerOne или Bugcrowd, каждая компанияучастник перечисляет зоны, попадающие под поиск уязвимостей, и находящиеся вне его. Надеюсь, вы уже их прочли и не тратили свое время впустую. Но если вы этого еще не делали, прочтите прямо сейчас. Убедитесь, что ваша находка еще никому неизвестна и не находится за пределами опубликованных компаниями программ.

Вот болезненный пример из моего прошлого - первую уязвимость я обнаружил на Shopify: если вы отправляли искаженный HTML в их текстовом редакторе, то синтаксический анализатор в этом редакторе исправлял его и запоминал XSS. Я был более чем взволнован. Моя охота за уязвимостями была не

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

Окрыленный, я нажал кнопку “отправить” и ждал своё вознаграждение в размере $500. Вместо этого, они вежливо сказали мне, что это была известная уязвимость, и они попросили исследователей больше не присылать эту уязвимость. Задача с уязвимостью была закрыта, а я потерял 5 баллов. Хотелось буквально зарыться в землю от досады, это был тяжелый урок.

Учитесь на моих ошибках, ЧИТАЙТЕ ИНСТРУКЦИИ!

Добавьте деталей. Затем добавьте больше деталей.

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

•URL и любые затронутые в исследованиях и поисках уязвимости параметры

•Описание браузера, операционной системы (если это важно) и/или версию приложения

•Описание предполагаемого воздействия. Как могла бы ошибка потенциально быть использована?

•Подробные шаги для воспроизведения этой ошибки

Эти критерии являются общими для всех крупных компаний на Hackerone, включая Yahoo, Twitter, Dropbox и прочих. Если вы хотите большего, я рекомендую включить в отчет скриншоты или видео. И то, и то очень сильно поможет компаниям разобраться в уязвимости.

На этом этапе вам также нужно учитывать то, какова опасность уязвимости для сайта. Например, XSS хранящиеся в

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

Подтвердите уязвимость

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

К примеру, если вы сообщаете о том, что компания не использует токен CSRF в их заголовках, смотрели ли вы, вдруг параметры включают токен, который действует как CSRF токен, но просто не имеет такой же ярлык?

Чрезвычайно важно убедиться, что вы нашли именно уязвимость, прежде чем представить отчет. Большим ударом будет посчитать, что вы нашли значительную уязвимость, а потом понять, что вы что-то неправильно истолковали во время тестов.

Сделайте себе одолжение, потратьте еще одну минуту чтобы удостовериться в том, что это уязвимость, прежде чем отправлять отчёт.

Проявляйте уважение к компании

На основе тестов в процессе создания компании в HackerOne (да, вы можете проверять сайт как исследователь), когда ком-

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

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

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

Во время написание этой книги мне улыбнулась удача пообщаться с Адамом Бахусом, новенький в команде HackerOne по состоянию на май 2016 года, он оказался обладателем титула Chief Bounty Officer и наш разговор открыл мне глаза на другую сторону программ по поиску уязвимостей. У Адама за плечами был опыт работы с Snapchat, где он был связующим звеном между командой безопасности, остальными командами программистов и Google, он работал в Команде по устранению уязвимостей и помогал в программе вознаграждения за поиск уязвимостей от Google.

Адам помог мне понять, что люди на другой стороне программы по поиску багов сталкиваются с кучей проблем, включая:

• Пустой шум: К сожалению, программы программы по

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

•Расставление приоритетов: Программы по поиску уяз-

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

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

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

•Исправление ошибок: Программирование занимает время, особенно если в него входит полный цикл разработки включая отладку, тестирование, стейджинг, деплой