Политика
- Пожалуйста, предоставляйте подробные отчеты с воспроизводимыми шагами.
- Отправляйте по одной уязвимости за отчет, если только вам не нужно связывать несколько уязвимостей в цепочку.
- В случае дублирования мы присуждаем награду только за первый полученный отчет (при условии, что его можно полностью воспроизвести).
- Объединяйте в один отчет уязвимости, у которых схожая основная причина (например, уязвимость библиотеки, которая используется на нескольких доменах из скопа).
- Если исправление одной из присланных уязвимостей исправит уязвимость из нового отчета, вознаграждается только первоначальный отчет.
- Максимально старайтесь избежать нарушений конфиденциальности, уничтожения данных, прерывания или ухудшения качества наших услуг. Взаимодействуйте только с вашими учетными записями или с явного разрешения владельца другой учетной записи.
- Не запускайте сканирование, которое может снизить производительность или привести к отказу в обслуживании целевых приложений.
- В случае тестирования службы электронной почты при регистрации указывайте внешнюю электронную почту и включите "bugbounty" в ее имя, чтобы мы знали, что это не настоящий злоумышленник.
- Не открывайте и не вносите изменения в учетные записи клиентов.
- Не проводите атаки социальной инженерии, включая фишинг.
- Не используйте спам.
- Не выполняйте никаких физических атак.
- Запрещено любое боковое перемещение и постэксплуатация после получения первоначального доступа.
- Для уязвимостей нулевого дня мы принимаем отчеты после первых двух недель с первой публикации уязвимости.
- Уязвимости типа RCE, SQL, SSRF вне критичной инфраструктуры будут оцениваться ниже. Из критичной инфраструктуры должен быть доступен хост rm.rambler-co.ru(10.99.2.223), ожидаемый ответ от данного хоста - 302.
Правила отчета
Отчет должен быть полноценным и понятным для проверяющего, содержать все необходимые шаги/команды/зависимости для воспроизведения уязвимости. Шаги необходимо расписывать подробно, с указанием того, что именно является уязвимым и как именно эксплуатировать эту уязвимость. Также необходимо приводить подтверждение - скриншоты запросов, результата, или видео с полной реализацией атаки и четкими указаниями каждого шага.
Помимо прочего, нужно описать потенциальные риски, от эксплуатации уязвимости, а также будем признательны, если вы опишите ещё и рекомендации по устранению.
Так как боковое перемещение запрещено для некоторых уязвимостей достаточно следующих демонстраций:
- SQL Injection – получение версии базы данных;
- XXE / XML injection – демонстрация факта XXE, кроме DOS;
- XSS – вывод алерта или сообщения в лог;
- RCE – hostname, id, ifconfig;
- SSRF – curl на внутренний домен (rm.rambler-co.ru(10.99.2.223), ожидаемый ответ от данного хоста - 302).
Таблица выплат
Наши выплаты основываются на критичности уязвимости по CVSS 3.0, однако в компании мы используем внутреннюю политику по управлению уязвимостями, где градация критичности отличается от CVSS. Таблица с необходимыми диапазонами критичности:
| Уровень критичности | Размер вознаграждения |
|---|
| Critical (9.9 - 10.0) | 55 000 - 150 000 рублей |
| High (8.0 - 9.8) | 30 000 – 55 000 рублей |
| Medium (4.0 - 7.9) | 3 000 – 25 000 рублей |
| Low (0.1 - 3.9) | 0 - 3 000 рублей |
Уязвимости
Основной упор мы хотим сделать на получении критичных уязвимостей:
- RCE;
- Injections;
- SSRF;
- LFI/RFI;
- XXE.
LiveJournal
Принимаются уязвимости на домене:
Принимаются только серверные уязвимости уровня «Критический» и «Высокий». Уязвимости, основная цель атаки которых - клиент (XSS, CSRF и т.д.), не считая атаки на пользователей с высокими привилегиями (XSS в админской панели), принимаются без оплаты
Уязвимости вне программы
- Clickjacking;
- CSRF на логин/логаут;
- Man in the middle;
- любые методы социальной инженерии;
- Self-XSS;
- любая вредоносная активность, которая может привести к отказу в обслуживании (DoS);
- результаты работы автоматических сканеров без реального POC;
- инъекции http-заголовков без серьезного влияния на безопасность (в том числе CRLF);
- SPF/DKIM/DMARC-мисконфигурации;
- SSL/TLS бест практики;
- атаки, требующие физического доступа к оборудованию компании;
- уязвимости в сторонних библиотеках, напрямую не ведущие к уязвимостям;
- отсутствие любых других бест практик, напрямую не ведущее к уязвимости;
- уязвимости, применимые только к пользователям с устаревшими браузерами;
- устаревшие DNS-записи;
- отсутствие флагов безопасности на некритичных куках;
- утечки информации через заголовок referer;
- утечки информации через /status или /metrics без конкретного влияния на безопасность.
Перечисленные ниже уязвимости мы принимаем как "Информационные", если они не несут за собой прямого или косвенного финансового риска:
- уязвимости Open Redirect, если они не участвуют в цепочке атаки с более серьезным вектором;
- уязвимости, результатом которых является накрутка каких-либо параметров пользователя (рейтинга, реакций, кол-ва подписчиков, репостов и т.д), если это не ведет напрямую к финансовым потерям (накрутка в конкурсе) и за исключением CSRF-атаки.