Bug Hunter: От первых шагов до профессионального Bug Bounty

Вопрос исследователя всегда один: из чего складывается ключ кэша и совпадает ли он с факторами, влияющими на ответ? Защита — согласовать ключ с реальными факторами (корректный Vary), не кэшировать приватные ответы (Cache-Control: private, no-store), нормализовать то, что влияет на ответ.

3.8. TLS: защита канала

TLS (Transport Layer Security) обеспечивает конфиденциальность и целостность канала и аутентификацию сервера сертификатом. HTTPS = HTTP поверх TLS. Что важно исследователю:

Рукопожатие согласует версию (TLS 1.2/1.3) и шифры, сервер предъявляет сертификат, цепочка которого проверяется до доверенного корня.

SNI (Server Name Indication) — имя хоста в рукопожатии (нужно для виртуального хостинга).

Certificate Transparency — публичные логи выданных сертификатов; ценный источник для разведки (поиск поддоменов, глава 5).

Без HTTPS данные видны и изменяемы на пути (MITM); отсюда важность HSTS (раздел 3.3).

Проверка TLS из командной строки:

Любой практический разбор в книге — на локальном HunterMart (http://127.0.0.1:8000) или на явно разрешённых целях. Обращение к чужим системам — только в рамках scope (глава 2).

3.9. Кэширование

Заголовки Cache-Control, ETag, Last-Modified, Vary управляют кэшированием (браузер, прокси, CDN). Условные запросы (If-None-Match) дают 304. Ключевой для безопасности вопрос: из чего складывается ключ кэша и совпадает ли он с тем, что реально влияет на ответ — отсюда cache poisoning и cache deception (продвинутые темы).

3.10. Практикум

Уровень 2. Поднимите HunterMart, выполните вход и запрос заказа через curl -v. Выпишите метод, путь, три значимых заголовка запроса, код ответа и content-type; объясните роль каждого заголовка.

Уровень 3. Снимите заголовки ответа любого эндпоинта и прогоните через huntkit.headers.analyze. Для каждой находки решите: это ослабление защиты или эксплуатируемая проблема? Что нужно, чтобы находка стала реальной уязвимостью?

Уровень 4. Проверьте TLS любого публичного сайта (как чтение сертификата, без тестирования) командой из раздела 3.8 и объясните, что означают поля subject/issuer/dates.

3.10a. Дополнительные задания (уровни 1–8)

Уровень 1. Разметьте части HTTP-запроса и ответа из раздела 3.2.1 (метод, цель, заголовки, тело).

Уровень 2. Через curl -v выполните вход и запрос заказа; выпишите три значимых заголовка.

Уровень 3. Снимите заголовки ответа и прогоните через huntkit.headers; классифицируйте находки.

Уровень 4. Проверьте разницу 401/403/404 на эндпоинтах HunterMart и объясните её.

Уровень 5. Разберите cookie-атрибуты гипотетического Set-Cookie и назначение каждого.

Уровень 6. Объясните на примере, почему GET, меняющий состояние, — проблема (CSRF/кэш).

Уровень 7. Опишите, как расхождение интерпретации на границе «прокси — сервер» порождает smuggling.

Уровень 8. Предложите набор security-заголовков для HunterMart и обоснуйте каждый.

3.11. Анализ ошибок новичка

Доверяют коду ответа как истине. 200 ≠ «всё хорошо», 404 ≠ «ничего нет».

Считают отсутствие security-заголовка готовой уязвимостью. Нужен контекст и влияние.

Путают HTTP-«безопасный метод» с защищённостью.

Игнорируют регистр и повторы заголовков. Повторяющиеся заголовки стороны объединяют по-разному — это бывает каналом атаки.

Забывают, что браузер — недоверенная сторона. Клиентские проверки не защищают.

3.12. Защитные меры (для разработчика)

Соблюдайте семантику методов; не меняйте состояние по GET.

Выставляйте security headers осознанно; не раскрывайте версии (Server, X-Powered-By).

Корректные атрибуты cookie (HttpOnly, Secure, SameSite); HSTS над HTTPS.

Явная политика кэширования приватных ответов (Cache-Control: private, no-store).

3.13. Резюме

Веб-приложение — распределённая система с границами доверия между браузером, прокси/CDN, сервером и базой. HTTP — протокол запрос–ответ без состояния с единой семантикой поверх версий транспорта; состояние надстраивают cookies и токены с атрибутами безопасности. TLS защищает канал и аутентифицирует сервер. Исследователь читает обмен по частям, не доверяет кодам и заявленному поведению, видит в заголовках и защиту, и каналы утечки. Эти основы используются во всех последующих главах.

3.14. Контрольные вопросы

Опишите путь запроса от браузера до базы и назовите, где проходят границы доверия.

Из каких частей состоит HTTP-сообщение? Чем обязателен Host в HTTP/1.1?

В чём разница 401/403 и почему их путаница помогает атакующему?

Зачем cookie-атрибуты HttpOnly, Secure, SameSite? Против каких атак каждый?

Что даёт TLS и почему важен HSTS?

Почему «нет CSP» — ослабление защиты, но не всегда готовая уязвимость?

3.15. Источники

RFC 9110 (HTTP Semantics), 9111 (Caching), 9112 (HTTP/1.1), 9113 (HTTP/2), 9114 (HTTP/3) — https://www.rfc-editor.org/ (проверено 2026-10-19).

RFC 6265 (Cookies) — https://www.rfc-editor.org/rfc/rfc6265.html (проверено 2026-10-19; атрибут SameSite описан в последующих обновлениях — сверяйте статус).

RFC 8446 (TLS 1.3) — https://www.rfc-editor.org/rfc/rfc8446.html (проверено 2026-10-19).

OWASP Secure Headers Project — https://owasp.org/www-project-secure-headers/ (проверено 2026-10-19).

MDN HTTP — https://developer.mozilla.org/en-US/docs/Web/HTTP (проверено 2026-10-19).

Глава 4. Linux, командная строка, Git и Python для исследователя

Цель главы. Собрать рабочий инструментарий исследователя: уверенная работа в Linux и терминале, обработка текста, Git для учёта экспериментов, и Python как язык автоматизации. Это прикладная глава: её навыки используются во всех практикумах и во всей части про инструменты (глава 12).

Предварительные требования. Главы 1–3. Доступ к Linux-окружению (или WSL/виртуальной машине).

Результаты обучения. Вы сможете: (1) уверенно двигаться по файловой системе и правам; (2) строить конвейеры обработки текста (grep/sed/awk/jq); (3) вести эксперименты в Git; (4) писать и запускать Python-скрипты в изолированном окружении (venv) с тестами.

4.1. Почему именно Linux

Большинство серверов, инструментов безопасности и примеров в сообществе — под Linux. Терминал даёт воспроизводимость (команду можно записать, повторить, автоматизировать) и прозрачность (видно, что именно происходит). Если у вас Windows — используйте WSL или виртуальную машину; если macOS — многое совпадает, но отдельные утилиты (sed, grep) отличаются флагами (BSD против GNU).

Заведите отдельную изолированную среду (ВМ или контейнер) для исследований: так вы не смешиваете рабочие инструменты с личными данными и можете безопасно «ломать» лабораторию.

4.2. Терминал и оболочка

Оболочка (shell, обычно bash) исполняет команды. Базовая модель: команда, аргументы, флаги.

Конвейеры (pipes) соединяют вывод одной команды со входом другой — основа мощи терминала:

Перенаправления: > (в файл, перезапись), >> (дописать), < (из файла), 2> (поток ошибок).

4.3. Файловая система и права

Linux — дерево от корня /. Важные места: /etc (конфигурация), /var/log (логи), /home (домашние каталоги), /tmp (временное). Пути бывают абсолютные (/home/user) и относительные (./file, ../up).

Права (ls -l показывает -rwxr-xr--): три группы (владелец, группа, остальные) по три бита (чтение r, запись w, исполнение x).

Для исследователя важно: по правам видно, кто и что может; неверные права на файлы с секретами — отдельный класс проблем (security misconfiguration).

4.4. Процессы, окружение, пакеты

Процессы: ps aux, top/htop, завершение — kill . Фоновый запуск — &, управление — jobs, fg, bg.

Переменные окружения: export NAME=value; env показывает текущие. Секреты часто передают через окружение — поэтому env и файлы вроде .env интересны (но чужие — только в scope!).

Пакеты: в Debian/Ubuntu — apt, обновления важны для безопасности самого рабочего места.

Скачанные файлы и распакованные архивы — недоверенные данные. Кладите каждый в отдельный пустой каталог, не запускайте интерпретаторы и сборщики «из» него (интерпретатор может подхватить код из текущего каталога), передавайте пути аргументами. Это гигиена вашего рабочего места.

4.5. Обработка текста: grep, sed, awk, jq

Исследование — это во многом обработка текста (логи, ответы, списки URL).

grep — поиск по шаблону (регулярные выражения):

sed — потоковое редактирование (замены):

awk — обработка по полям (столбцам):

jq — работа с JSON (незаменима для API):

sort | uniq -c | sort -rn — частотный анализ (топ значений):

4.5.1. Worked-пример: разбор лога запросов

Пусть есть файл access.log в типовом формате (IP, время, «метод путь протокол», код, размер):

Полезные выжимки:

Эти приёмы — повседневный инструмент при анализе логов, ответов и списков URL; те же awk/sort/uniq применяются к выводу разведки (глава 5) и к результатам инструментов (глава 12).

4.8.1. Worked-пример: Python для анализа JSON-ответа

Типичная задача — обработать JSON-ответ API. Пусть ответ сохранён в resp.json:

Обратите внимание на оборонительный стиль: .get(...) с запасным значением вместо data["results"] — данные из внешнего источника неполны и враждебны по умолчанию (принцип границы доверия, глава 1). Этот же стиль мы применяем в инструментах huntkit (глава 12): любые внешние данные обрабатываются так, будто они могут быть некорректными.

4.6. Сетевая диагностика из терминала

curl -v — отправить запрос и увидеть весь обмен (основной инструмент, глава 3).

dig — DNS-запросы (записи A/AAAA/CNAME/MX/TXT), основа разведки (глава 5).

openssl s_client — ручной разбор TLS-рукопожатия и сертификата (глава 3).

ss -tlnp — какие порты слушает ваша машина (полезно для локальной лаборатории).

4.7. Git: учёт экспериментов

Git — система контроля версий. Для исследователя это не только про код: это журнал гипотез, результатов и инструментов, который можно откатить и сравнить.

Практика этой книги хранится в Git именно так: каждый блок работы — отдельный коммит, что даёт git diff для проверки и возможность отката (мы использовали это при переименовании проекта).

В .gitignore держите секреты, виртуальные окружения и кэши (.venv/, .env, __pycache__/). Случайный коммит секрета — частая и опасная ошибка.

4.7.1. Worked-пример: Git-рабочий процесс исследователя

Покажем минимальный цикл, которым удобно вести и код инструментов, и журнал экспериментов:

Зачем это исследователю: (1) воспроизводимость — к любому состоянию можно вернуться; (2) журнал — коммиты фиксируют ход мысли и находки; (3) откат — ошибочное изменение легко отменить. Именно так ведётся репозиторий этой книги: каждый блок работы — отдельный коммит, что даёт git diff для проверки и возможность отмены (мы использовали это при переименовании учебного проекта). Правило гигиены: секреты и окружение — всегда в .gitignore, проверяйте git status перед коммитом.

4.8. Python для исследователя: основы

Python — язык автоматизации в безопасности: читаемый, с богатой стандартной библиотекой и экосистемой. Книга использует Python 3.12. Минимум, нужный, чтобы начать (полноценно — глава 12):

Работа с JSON и файлами (типичные задачи исследователя):

4.9. Изолированное окружение и зависимости

Никогда не ставьте пакеты глобально для проектов — используйте виртуальное окружение (venv):

Зависимости фиксируйте с версиями (requirements.txt), чтобы примеры были воспроизводимы. Книга фиксирует версии и дату проверки совместимости (2026-10-19).

4.10. Тестирование кода

Инструмент без тестов легко ломается незаметно. Минимальный тест на pytest:

Инструменты книги (huntkit.*) сопровождаются автоматическими тестами и проверкой стиля и типов; это стандарт качества, которого мы придерживаемся во всех листингах (глава 12).

4.11. Практикум

Уровень 2. Соберите конвейер: из файла со списком URL оставьте только уникальные хосты, отсортируйте по частоте. (Подсказка: awk -F/ '{print $3}' | sort | uniq -c | sort -rn.)

Уровень 3. Напишите Python-скрипт, который читает JSON-ответ /api/products/search из файла и печатает названия товаров. Добавьте обработку случая «ключа results нет».

Уровень 4. Инициализируйте Git в учебном каталоге, сделайте два коммита с изменением файла и покажите git diff между ними. Объясните, зачем исследователю история экспериментов.

4.11a. Дополнительные задания (уровни 1–6)

Уровень 1. Объясните, что делает конвейер и перенаправление на примере cmd > out 2> err.

Уровень 2. Из лог-файла (раздел 4.5.1) выведите топ-5 IP и все 4xx/5xx.

Уровень 2. Прочитайте права -rwxr-x--- и запишите эквивалентный chmod.

Уровень 3. Напишите Python-скрипт, читающий JSON-ответ и печатающий поля с безопасным доступом.

Уровень 4. Инициализируйте Git, сделайте два коммита и покажите git diff между ними.

Уровень 5. Напишите функцию с типами и тестом на pytest; прогоните ruff и mypy.

Уровень 6. Соберите мини-конвейер из curl + jq + sort|uniq -c для анализа ответа API.

4.12. Анализ ошибок новичка

Ставят пакеты глобально и получают конфликты версий — используйте venv.

Коммитят секреты и .venv — настройте .gitignore заранее.

Путают BSD и GNU утилиты (macOS/Linux) — проверяйте флаги.

Запускают код «из» каталога со скачанными данными — риск подхвата чужого кода.

Пишут инструменты без тестов — незаметные регрессии.

4.13. Резюме

Рабочее место исследователя — это Linux и терминал (навигация, права, процессы, окружение), мощная обработка текста (grep/sed/awk/jq), сетевая диагностика (curl/dig/openssl), Git для учёта экспериментов и Python для автоматизации в изолированном окружении с тестами. Эти навыки — несущая конструкция всех практикумов и главы 12.

4.14. Контрольные вопросы

Что делает конвейер cat f | grep X | wc -l и как заменить cat более идиоматично?

Как прочитать права -rwxr-x--- и что означает chmod 750?

Какие инструменты вы примените для JSON, для полей лога, для замен в тексте?

Зачем venv и почему зависимости фиксируют с версиями?

Почему историю экспериментов полезно вести в Git?

Почему скачанные данные держат в отдельном каталоге и не запускают интерпретатор «из» него?

4.15. Источники

The Linux Documentation Project — https://tldp.org/ (проверено 2026-10-19).

GNU Coreutils / grep / sed / gawk manuals — https://www.gnu.org/manual/ (проверено 2026-10-19).

jq manual — https://jqlang.github.io/jq/manual/ (проверено 2026-10-19).

Pro Git (книга) — https://git-scm.com/book