Rambler&Co

Политика

• Пожалуйста, предоставляйте подробные отчеты с воспроизводимыми шагами.
• Отправляйте по одной уязвимости за отчет, если только вам не нужно связывать несколько уязвимостей в цепочку.
• В случае дублирования мы присуждаем награду только за первый полученный отчет (при условии, что его можно полностью воспроизвести).
• Объединяйте в один отчет уязвимости, у которых схожая основная причина (например, уязвимость библиотеки, которая используется на нескольких доменах из скопа).
• Если исправление одной из присланных уязвимостей исправит уязвимость из нового отчета, вознаграждается только первоначальный отчет.
• Максимально старайтесь избежать нарушений конфиденциальности, уничтожения данных, прерывания или ухудшения качества наших услуг. Взаимодействуйте только с вашими учетными записями или с явного разрешения владельца другой учетной записи.
• Не запускайте сканирование, которое может снизить производительность или привести к отказу в обслуживании целевых приложений.
• В случае тестирования службы электронной почты при регистрации указывайте внешнюю электронную почту и включите "bugbounty" в ее имя, чтобы мы знали, что это не настоящий злоумышленник.
• Не открывайте и не вносите изменения в учетные записи клиентов.
• Не проводите атаки социальной инженерии, включая фишинг.
• Не используйте спам.
• Не выполняйте никаких физических атак.
• Запрещено любое боковое перемещение и постэксплуатация после получения первоначального доступа.
• Для уязвимостей нулевого дня мы принимаем отчеты после первых двух недель с первой публикации уязвимости.
• Уязвимости типа RCE, SQL, SSRF вне критичной инфраструктуры будут оцениваться ниже. Из критичной инфраструктуры должен быть доступен хост load.rambler-co.ru(10.99.2.96).

Правила отчета

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

• SQL Injection – получение версии базы данных;
• XXE / XML injection – демонстрация факта XXE, кроме DOS;
• XSS – вывод алерта или сообщения в лог;
• RCE – hostname, id, ifconfig;
• SSRF – curl на внутренний домен (load.rambler-co.ru(10.99.2.96)).

Таблица выплат

Наши выплаты основываются на критичности уязвимости по CVSS 3.0, однако в компании мы используем внутреннюю политику по управлению уязвимостями, где градация критичности отличается от CVSS. Таблица с необходимыми диапазонами критичности:

Уязвимости

Основной упор мы хотим сделать на получении критичных уязвимостей:

• RCE;
• Injections;
• SSRF;
• LFI/RFI;
• XXE.

Уязвимости вне программы

• Clickjacking;
• CSRF на логин/логаут;
• Man in the middle;
• любые методы социальной инженерии;
• Self-XSS;
• любая вредоносная активность, которая может привести к отказу в обслуживании (DoS);
• результаты работы автоматических сканеров без реального POC;
• инъекции http-заголовков без серьезного влияния на безопасность (в том числе CRLF);
• SPF/DKIM/DMARC-мисконфигурации;
• SSL/TLS бест практики;
• атаки, требующие физического доступа к оборудованию компании;
• уязвимости в сторонних библиотеках, напрямую не ведущие к уязвимостям;
• отсутствие любых других бест практик, напрямую не ведущее к уязвимости;
• уязвимости, применимые только к пользователям с устаревшими браузерами;
• устаревшие DNS-записи;
• отсутствие флагов безопасности на некритичных куках;
• утечки информации через заголовок referer;
• утечки информации через /status или /metrics без конкретного влияния на безопасность.

Перечисленные ниже уязвимости мы принимаем как "Информационные", если они не несут за собой прямого или косвенного финансового риска:

• уязвимости Open Redirect, если они не участвуют в цепочке атаки с более серьезным вектором;
• уязвимости, результатом которых является накрутка каких-либо параметров пользователя (рейтинга, реакций, кол-ва подписчиков, репостов и т.д), если это не ведет напрямую к финансовым потерям (накрутка в конкурсе) и за исключением CSRF-атаки.