Правила работы в bug bounty: скоуп, safe harbour и раскрытие

#Что такое программа bug bounty

Программа bug bounty — это постоянное приглашение от организации тестировать её публичные системы и сообщать об уязвимостях, обычно за вознаграждение. У приглашения есть условия. Обычно их называют политикой. Они определяют, какие системы можно тестировать, какими способами, чего трогать нельзя, как сообщать о находках и что организация обещает взамен.

Политика — это свод правил. Проблемы часто начинаются там, где исследователь её пропустил или прочитал как формальность. Лаборатория учит находить уязвимость. Политика программы учит понимать, где вам разрешено искать и когда остановиться на границе разрешения. Эта статья о втором навыке.

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

#Почему правила идут раньше тестирования

Первой причиной обычно называют юридические риски, и они настоящие. Законы о неправомерном использовании компьютеров во многих странах написаны настолько широко, что обвинение за доступ без разрешения возможно даже при добрых намерениях. Самый известный пример — Computer Fraud and Abuse Act (CFAA) в США. В мае 2022 года Министерство юстиции США изменило порядок, по которому его прокуроры предъявляют обвинения за добросовестные исследования безопасности по этому закону. Обновлённая политика предписывает прокурорам не предъявлять обвинений за исследования, которые проводятся исключительно ради тестирования, изучения или исправления уязвимости, не причиняют вреда и результаты которых используются в основном для улучшения безопасности. Сам закон она не меняет. Исследования ради вымогательства она не защищает. Это политика предъявления обвинений, а не закреплённое законом право, и она не связывает прокуроров штатов и частных лиц, подающих иски. Точную формулировку смотрите в объявлении Министерства юстиции. Не считайте её разрешением тестировать что угодно.

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

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

#Как читать политику программы, шаг за шагом

Каждый раз проходите политику в одном и том же порядке. Каждый раздел ниже — вопрос, на который вы должны уметь ответить до того, как с вашей машины уйдёт первый запрос.

#1. Активы в скоупе и вне скоупа

Скоуп — это список активов, которые владелец разрешает тестировать. Актив может быть доменом, диапазоном IP-адресов, мобильным приложением, API, продуктом или типом аккаунта. Хорошая политика называет каждый актив точно и указывает, охватывает ли шаблон вроде *.example.test все поддомены.

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

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

#2. Разрешённые и запрещённые техники

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

Перед началом запишите список своими словами: «Разрешено: ручное тестирование веб-приложения с тестовым аккаунтом. Запрещено: отказ в обслуживании, фишинг сотрудников, сканеры». Если записать не получается, к тестированию вы не готовы.

#3. Лимиты запросов и нагрузка

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

Занесите это число в чек-лист. Настройте инструмент так, чтобы он его соблюдал, и проверьте настройку перед началом.

#4. Тестовые аккаунты

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

#5. Обращение с данными

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

На правиле об остановке при персональных данных спотыкаются многие. Если небезопасная прямая ссылка на объект (IDOR) открывает чужую запись, правильное доказательство — это обычно идентификатор и краткое описание. Дамп таблицы для этого не нужен. Запишите, что увидели, а остальное оставьте на месте.

#6. Формулировки safe harbour

Safe harbour — это обещание владельца не начинать юридических действий против исследователей, которые действуют добросовестно и в соответствии с политикой. Проект disclose.io публикует формулировки safe harbour и инструменты для организаций, которые хотят написать свои. На сайте проекта цель описана так: дать людям сообщать о проблемах безопасности без страха юридических последствий. Там же указано, что материалы юридической консультацией не считаются.

Текст safe harbour читайте внимательно. В хорошей формулировке названы условия: следовать политике, сообщать без промедления, не использовать доступ ни для чего другого. Она также распространяется на системы самой программы. Обещание одной компании не покрывает третью сторону или не связанные с программой действия. Если safe harbour в политике нет вообще, взвесьте это перед тестом.

#7. Контакты и условия раскрытия

Раздел контактов говорит, куда отправлять отчёт и как владелец ответит. Ищите контакт службы безопасности, почтовый ящик на платформе или файл security.txt в /.well-known/. Посмотрите, в какой срок подтверждают получение и что происходит с находкой после исправления.

Условия раскрытия говорят, когда можно публиковать. Некоторые политики разрешают публикацию после выхода исправления. Другие задают фиксированное окно с момента первого отчёта. На странице CISA о скоординированном раскрытии уязвимостей сказано, что если вендор не отвечает или не соглашается на разумный срок, CISA может раскрыть информацию уже через 45 дней после первой попытки связаться с ним. Это правило CISA для её собственной роли, универсальным сроком оно не служит. Ваши условия задаёт политика программы, и раньше, чем она разрешает, вы не публикуете.

#Скоординированное раскрытие уязвимостей

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

ISO/IEC 29147, с названием «Vulnerability disclosure» в серии Information technology, Security techniques, — международный стандарт для внешней стороны этого процесса. Он описывает, как вендор получает отчёты, общается с сообщившим, координируется с другими вендорами и публикует бюллетени. Парный к нему документ, ISO/IEC 30111, описывает, как вендор работает с уязвимостью внутри компании. В каталоге ISO документ числится как второе издание 2018 года. Прежде чем на него ссылаться, проверьте текущий статус на iso.org.

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

#Почему тест вне скоупа под запретом

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

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

Честный ответ на вопрос о скоупе — письменно спросить программу до теста или пропустить актив. Короткий вопрос обходится намного дешевле юридического спора.

#Практика: размечаем образец политики и составляем чек-лист

Лаборатория для этого раздела не нужна. Программа в образце вымышленная и использует зарезервированный домен example.test. Вы прочитаете её, разметите и проверите чек-лист небольшим скриптом на своей машине. Запросов к настоящим хостам здесь нет.

#Образец политики

Сохраните этот текст как sample-policy.md в пустой папке.

Example Widget Co. Vulnerability Disclosure Program (fictional)

1. Scope
   In scope: *.example.test and api.example.test.
   Out of scope: payments.example.test (hosted by a payment provider),
   any third-party SaaS host, staging-old.example.test.

2. Techniques
   Allowed: manual testing with a test account you created.
   Allowed: automated scanners at no more than 2 requests per second.
   Forbidden: denial of service, phishing or contacting staff, physical access.

3. Test accounts
   Create accounts with the suffix [email protected].
   Do not use accounts that belong to customers.

4. Data
   If you reach personal data, stop and report the identifier only.
   Delete copies within 30 days of the report being closed.

5. Safe harbour
   We will not pursue legal action against good-faith research that follows
   this policy.

6. Reporting
   Send reports to [email protected]. We acknowledge within 3 business days.
   We ask for 90 days between first report and public disclosure.

#Упражнение на разметку

Скопируйте политику в текстовый файл и пометьте каждую строку одной из четырёх меток: [SCOPE], [RULE], [ASK] или [GAP]. ASK ставьте, когда перед тестированием нужно уточнить что-то у программы. GAP — когда политика молчит о том, что вам нужно.

Затем письменно ответьте на вопросы ниже. Цитируйте строку, в которой содержится ответ, и не отвечайте по памяти.

1. Распространяются ли на api.example.test те же правила, что и на основной сайт, или его нужно проверять отдельно?
2. Лимит запросов относится только к сканерам или и к ручному трафику тоже?
3. Какой статус у payments.example.test и что вы сделаете, если тест случайно туда попадёт?
4. Покрывает ли safe harbour находку, которая раскрывает данные клиентов?
5. Какая часть условий раскрытия — обязательство владельца, а какая — просьба к вам?

На вопрос 4 в тексте ответа нет. Пометьте его GAP и напишите вопрос, который вы отправили бы программе.

#Чек-лист перед тестом

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

# Pre-test checklist

- [ ] written scope:
- [ ] excluded assets:
- [ ] allowed techniques:
- [ ] test account rules:
- [ ] data handling:
- [ ] contact and disclosure terms:

Заполните каждую строку ответом и поставьте рядом цитату из политики. Пункт, который вы не можете заполнить, — это открытый вопрос, и пока он не закрыт, не тестируйте.

#Проверка чек-листа скриптом

Сохраните скрипт ниже как precheck.py в той же папке. Он читает локальный текстовый файл и никуда не подключается.

import re, sys

REQUIRED = [
    "written scope",
    "excluded assets",
    "allowed techniques",
    "test account rules",
    "data handling",
    "contact and disclosure terms",
]

def read_fields(path):
    fields = {}
    with open(path, encoding="utf-8") as f:
        for line in f:
            m = re.match(r"^- \[( |x)\] ([^:]+):\s*(.*)$", line.rstrip("\n"))
            if m:
                fields[m.group(2).strip().lower()] = (m.group(1) == "x", m.group(3).strip())
    return fields

fields = read_fields(sys.argv[1])
missing = 0
for name in REQUIRED:
    if name not in fields:
        print(f"MISSING LINE: {name}")
        missing += 1
        continue
    done, value = fields[name]
    if not done or not value or value.upper() in ("TBD", "?"):
        print(f"OPEN: {name}")
        missing += 1
    else:
        print(f"OK: {name}")
print(f"{len(REQUIRED) - missing} of {len(REQUIRED)} items closed")
sys.exit(1 if missing else 0)

Запустите его из Git Bash в папке, где лежат оба файла:

python precheck.py checklist.md
echo "exit=$?"

Автор запускал это на машине с Windows 11 и Git Bash, с чек-листом, где в строке тестового аккаунта всё ещё стояло TBD. Вывод был таким:

OK: written scope
OK: excluded assets
OK: allowed techniques
OPEN: test account rules
OK: data handling
OK: contact and disclosure terms
5 of 6 items closed
exit=1

Скрипт отмечает открытый пункт и завершается со статусом 1, так что обёртка может остановить тест. Он проверяет только полноту формы. Соответствует ли запись политике, он определить не может, поэтому рядом с каждой записью нужна цитируемая строка.

#Частые ошибки

• Принимать название программы за скоуп. Программа с названием «Example Widget» может охватывать один продукт, несколько компаний или ни одну из дочерних компаний, которые вы имеете в виду. Читайте список.
• Тестировать угаданный или доставшийся по наследству актив. Поддомен, который вы угадали, или адрес из старой публичной записи остаётся вне скоупа, пока его не укажет политика.
• Запускать сканер на полной скорости, потому что политика молчит о лимитах. Молчание о лимитах не разрешает работать быстро.
• Хранить данные после отчёта. Копии, оставшиеся на ноутбуке, всё равно остаются данными владельца, и политика может требовать их удаления.
• Публиковать раньше срока, потому что вендор ответил «исправлено». Прочитайте условия раскрытия и дождитесь срока.
• Писать отчёт, который доказывает больше, чем вам разрешено было собрать. Идентификатор и одно замазанное поле обычно доказывают проблему не хуже дампа.
• Считать, что safe harbour покрывает всё. Он покрывает то, что написано в его тексте, для систем, которые в нём названы.

#Что дальше

Тренируйте привычку читать на публичных программах, которые публикуют свои правила. Ведите по одному чек-листу на программу и перечитывайте политику в день теста, потому что скоуп меняется. Прочитайте целиком материалы disclose.io о safe harbour и страницу CISA о скоординированном раскрытии. Разберитесь в разнице между политикой раскрытия уязвимостей, которая может не предлагать вознаграждения, и программой bug bounty, которая платит за находки. Затем прочитайте, как написать первый отчёт о безопасности, чтобы увидеть, как должна выглядеть находка, когда разрешение есть и что-то найдено.

Записывайте, что, когда и с какого аккаунта вы тестировали. Если через несколько месяцев возникнет вопрос, эти заметки будут вашим доказательством.

Технические навыки нарабатывайте в изолированной лаборатории, чужие системы для этого не годятся. Шаги описаны в статье как создать изолированную сеть Docker для лабораторий. У публичной информации тоже есть свои границы, о них в статье этика и приватность в OSINT.

#Источники

• disclose.io, safe harbour and policy tools: https://disclose.io/
• ISO/IEC 29147, Information technology, Security techniques, Vulnerability disclosure: https://www.iso.org/standard/72311.html
• CISA, Coordinated Vulnerability Disclosure Process: https://www.cisa.gov/coordinated-vulnerability-disclosure-process
• U.S. Department of Justice, New Policy for Charging Cases Under the Computer Fraud and Abuse Act (May 2022): https://www.justice.gov/opa/pr/department-justice-announces-new-policy-charging-cases-under-computer-fraud-and-abuse-act