- PVSM.RU - https://www.pvsm.ru -
Сегодня у многих IT-компаний есть собственные bounty-программы (или программы по поиску уязвимостей). Badoo — в их числе.
В этой статье я расскажу о том, как мы, не имея отдела информационной безопасности, запустили и ведем свою bounty-программу. Я расскажу о проблемах, с которыми мы столкнулись, как их решали и каким образом пришли к тому, что у нас сейчас есть. И, конечно, упомяну о некоторых интересных багах, присланных участниками этой программы.
Со времени старта нашей bounty-программы прошло три года. Нам до сих пор продолжают присылать сообщения участники со всего мира.
Мы хотим усилить интерес к ней, в том числе со стороны иностранных исследователей. Поэтому мы, во-первых, открыли страничку с нашей программой на крупнейшем портале исследователей hackerone.com [1], а во-вторых — увеличили суммы вознаграждений за найденные уязвимости! Теперь сумма вознаграждения, в зависимости от категории, начинается от £100 и может достигать £1000, сумма супер-премии составляет £2000 (а это более 200 000 рублей по текущему курсу!) и даже больше, если обнаруженная уязвимость представляет реальную угрозу для наших пользователей.
Badoo — это крупнейший в мире сервис знакомств. Тут можно встретить свою любовь, завести новых друзей или же просто найти собеседников, находящихся поблизости.
На сегодняшний день в Badoo зарегистрировано более 300 миллионов пользователей, которые говорят более чем на 50 языках и живут по всему миру. Работу этой системы поддерживают около 3000 серверов, расположенных в четырех дата-центрах (в Америке, Европе, Азии и России). Наш продукт — это набор приложений для всех популярных мобильных платформ, мобильный веб и веб-версия для десктопного браузера. Мы — highload-проект, и в пиках трафика у нас 70-80 тысяч запросов в секунду.
Очевидно, что система довольно масштабная и требует немало работы по разным направлениям, в том числе и в сфере информационной безопасности.
Как это ни странно, у нас нет отдела информационной безопасности. И специалистов, занимающихся исключительно этим направлением, у нас тоже нет.
Тем не менее мы дорожим нашими пользователями и заботимся о безопасности их данных. Несмотря на то, что мы не банк, не система онлайн-платежей и у нас нет возможности вывода средств (но есть зачисление средств, которые переводятся во внутреннюю валюту «кредиты Badoo»), у нас довольно много данных, которые надо защищать.
Масла в огонь подливает и продиктованная бизнесом необходимость не лишать пользователей удобства. Так, например, у нас есть фича, когда в письме пользователю имеется прямая ссылка на доступ к аккаунту без небходимости ввода логина и пароля. Очевидно, что это огромный риск с точки зрения безопасности. Мы стараемся подстраховаться по максимуму, и у нас имеются механизмы защиты данных пользователя даже в этом случае. Но, конечно, никто не идеален.
Почему у нас нет выделенного отдела — сложный вопрос, отвечая на который я бы хотел напомнить, что наш проект вырос из стартапа. А любой стартап изначально нацелен на быстрое развитие и достижение бизнес-целей; он не сильно фокусируется на качестве, безопасности и прочих очевидных для зрелых проектов аспектах. Именно поэтому большинство стартапов задумывается о своем отделе тестирования далеко не с самого начала, а об отделе информацинной безопасности и того позже. И это нормально.
До сих пор в нашей компании применяются некоторые методы и подходы, характерные для стартапа. Информационной безопасностью в целом мы занимались с самого начала (наши ребята — профессионалы своего дела), но вот системного подхода не было. Вероятно, когда-нибудь и мы придем к необходимости в отдельных специалистах или целом отделе, занимающемся информационной безопасностью.
А сегодня мы обеспечиваем безопасность и поддерживаем bounty-программу следующим образом:
Давным-давно нам, бывало, помогали сторонние специалисты по безопасности. Кого-то мы просили сами, кто-то писал нам о багах по собственной воле и получал за это вознаграждение. Но сам процесс был неорганизованным, поэтому мы решили его систематизировать, упорядочить и поставить на поток.
Пару лет назад мы всерьез задумались о постоянной bounty-программе, тем более что, с одной стороны, это своего рода челлендж, который позволил бы нам выйти на новый уровень, а с другой — независимая проверка, которая помогла бы нам понять, как обстоят наши дела с безопасностью.
Разумеется, мы не стали сразу браться за реализацию, а начали с подготовки и провели несколько внутренних проверок, чтобы повысить уверенность в том, что мы готовы.
В интерфейсе корпоративного сайта мы сделали страничку, куда выводились заявки, их статусы и категории. Описание уязвимостей появлялись на этой странице только после того, как уязвимость закрывалась. Новую заявку можно было отправить нам через эту же страницу.
Это оказалось очень удобно: люди получали в письме от нас номер заявки и могли следить за ее состоянием в этом же списке. А еще они могли давать ссылку на эту страницу другим, повышая собственную карму.
В качестве дополнительной мотивации мы сделали рейтинг участников, в котором принималось во внимание не только количество принятых заявок от конкретного участника, но и их критичнось. После окончания месячника мы наградили лидеров рейтинга специальными призами.
Эта страничка также помогала нам указывать участникам на дубликаты. В случае дублирования участник получал уведомление с номером уже принятой заявки. В результате он мог на этой странице отслеживать статус таких заявок.
При оценке багов, найденных участниками, мы не стали опираться на распространенные системы оценок уязвимостей, таких как, к примеру, OWASP. Напротив, мы решили присуждать категорию в зависимости от потенциального ущерба, который уязвимость можно нанести нам и нашим пользователям. Таких категорий мы ввели 5, и в денежном эквиваленте они оценивались в сумму от 50 до 500 фунтов стерлингов.
На первый взгляд, это может показаться странным, но мы руководствовались тем, что зачастую не самая критичная по версии OWASP уязвимость может нанести нам серьезный вред, поэтому ее надо оценивать выше. К тому же мы предусмотрели супер-премию в £2000 и выше в случае обнаружения особо критичной уязвимости. Так мы решили дополнительно мотивировать наших исследователей не только сообщать об уязвимости, но и придумать для нее максимально эффективный вектор эксплуатации. Далее в статье я приведу пример простой XSS-уязвимости, за которую мы выдали супер-премию из-за необычного и очень интересного вектора атаки.
Итак, «день Д» наступил. Мы запустили программу, анонсировав ее в нескольких источниках, и стали ждать результатов. Напомню, что мы запускали ее всего лишь на месяц. Он был напряженным, но очень полезным для нас. Результаты «месячника безопасности» в Badoo были такими:
Основной процент багов, присланных в течение нескольких дней, составили CSRF. Затронуты были в основном страницы, на которых пользователи заполняли информацию о себе, загружали фото и так далее. Нельзя сказать, что защиты от CSRF-атак на тот момент у нас совсем не было. Многие страницы были защищены сессионным токеном. Тем не менее, как оказалось, не все действия пользователя на сайте были защищены от CSRF-угроз.
Мы отреагировали быстро и уже через несколько дней после старта конкурса запустили большой проект по защите пользовательских данных — анти-CSRF. Все страницы и веб-сервисы мы переделали таким образом, чтобы они стали проверять CSRF-токены по умолчанию. Так мы закрыли практически все CSRF-уязвимости на сайте.
Топ-3 наиглупейших багов, полученных во время первого «месячника безопасности» выглядели так:
За месяц конкурса мы научились реагировать на заявки от участников в течение нескольких часов, починили баги и создали отдельный проект по защите от CSRF-атак. Стало понятно, что эта программа — дело хорошее и нужное. Она полностью оправдала время и ресурсы, затраченные на ее подготовку и реализацию. Поэтому мы решили двигаться дальше и стали готовиться к постоянной программе по поиску уязвимостей в системе безопасности Badoo, немного изменив формат.
В течение месячника мы поняли, как должен выглядеть удобный flow для обработки заявок, и перевели его в JIRA, поскольку трекинг всех задач в нашей компании делается именно в этой системе.
Простой flow в Google Группах выглядел следующим образом:
Заявки от участников попадали к нам двумя путями: через форму на корпоративном сайте и специальный email-адрес. Далее жюри конкурса оценивало заявки и отправляло их (в случае реальных угроз) в разработку конкретным командам. Общаться с участниками на этом этапе нам помогала Developer relations manager, хотя многие письма можно было генерировать автоматически.
Flow в Jira, который мы сделали для постоянной программы, выглядел немного иначе и уже включал в себя автоматические ответы участникам, исключая человеческий фактор.
Также в постоянную программу мы решили добавить и мобильные приложения.
Примерно в то же время мы попали в список bounty-программ Bugcrowd [2], что принесло нам дополнительную популярность и привлекло внимание исследователей со всего мира. Усилив анонсирование, мы запустили программу.
Результаты не были такими же впечатляющими, как после месячника — поток нерелевантных репортов об узявимостях был больше. Тем не менее за первый год работы «большой» программы мы получили сообщения о нескольких интересных багах.
Как и ожидалось, «шума» стало больше, но и полезных репортов тоже было немало, поэтому результатом программы в целом мы довольны.
Много интересных багов за первый год нам прислали про мобильные приложения, что, несомненно, приятно. Эта область новая и интересная для разработчиков и исследователей.
Топ-3 багов, найденных за первый год программы:
В целом мы считаем, что bounty-программа принесла нам положительный и полезный опыт. Мы ежедневно получаем экспертную оценку наших приложений и сайтов от множества исследователей по всему миру и работаем над улучшением своих продуктов, следя за новостями из области информационной безопасности. Мы высоко ценим доверие наших пользователей и стараемся сделать все, чтобы сохранить безопасность их данных.
Участвуйте в нашей программе, ищите баги на сайтах и в приложениях других компаний. Это очень занимательный процесс, который может не только принести вам положительные эмоции и интересные знания, но и еще и внести существенный вклад в ваш бюджет. Мы платим в фунтах стерлингов, а недавно еще и значительно увеличили суммы премий.
Присылать нам сообщения об уязвимостях или багах лучше всего через платформу Hackerone [1]. Удачного баг-хантинга!
Илья Агеев,
Head of QA, Badoo.
PS: Пока писалась статья, нам в программе на Hackerone [1] сообщили о новых и интересных уязвимостях. О них мы обязательно напишем подробно в следующий раз.
Автор: Badoo
Источник [3]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/php-2/115058
Ссылки в тексте:
[1] hackerone.com: https://hackerone.com/badoo
[2] Bugcrowd: https://bugcrowd.com/list-of-bug-bounty-programs
[3] Источник: https://habrahabr.ru/post/279325/
Нажмите здесь для печати.