Как начать охоту за ошибками!

Прежде чем переходить к технике поиска уязвимостей, стоит понимать: найти баг — это только половина дела. Компании и площадки Bug Bounty платят не за сам факт находки, а за качественно оформленный отчёт (report). В нём обязательно должны быть чёткие шаги воспроизведения (steps to reproduce), скриншоты или видео, описание impact — к чему уязвимость реально может привести, и рекомендации по исправлению. Расплывчатый или неполный отчёт с высокой вероятностью будет отклонён или получит минимальную награду, даже если баг критический. Держите это в голове на каждом этапе тестирования — фиксируйте запросы и результаты сразу, чтобы потом не восстанавливать цепочку действий заново.

---

Краткое и базовое введение в Bug Bounty.



Я рекомендую зарегистрироваться на следующих краудсорсинговых платформах кибербезопасности (платформы Bug Bounty):
https://www.bugcrowd.com
https://www.hackerone.com
https://www.intigriti.com

Поиск ошибок в дикой природе (не на платформе Bug Bounty) может быть хорошим, но это может быть не лучшее место для начала, поскольку нет гарантии, что компания ответит на ваш отчет или что вы получите какое-либо вознаграждение или признание вашей работы.
Платформы Bug Bounty могут предлагать частные приглашения с течением времени, что может обеспечить вам более низкую конкуренцию по сравнению с публичными программами, увеличивая ваши шансы найти что-то уникальное.
Попробуйте сосредоточиться на программах с широкими возможностями, где вы можете управлять пользователями (создавать роли), документами, изображениями и т. д.
А затем начните с простого — создайте двух пользователей (один обычный пользователь и второй администратор), откройте два браузера и начните тестирование на уязвимость BAC (Broken Access Control).

Вкратце — это тип уязвимости, где обычный пользователь может выполнять административные действия.
Некоторые из этих уязвимостей можно найти с помощью прямых ссылок на разделы/конечные точки, но другие потребуют от вас модификации запросов, отправляемых в браузер.
Я рекомендую использовать Burp Suite для захвата и модификации запросов. Вы можете скачать Community Edition бесплатно.

Рекомендуемый аддон: Logger++

При тестировании сайта/приложения на BAC-баги — можно выделить все GET-запросы к критическим действиям. Например: /delete_user?id=1

Запросы с критическими действиями (такими как удаление пользователя), которые могут быть отправлены непосредственно пользователю, рассматриваются как уязвимость CSRF (подделка межсайтовых запросов).
POST-запросы также могут использоваться для выполнения атаки CSRF, но обычно имеют механизм защиты от CSRF (например, csrf_tokens или проверку реферера).
Иногда защиту от CSRF можно обойти. Попробуйте переключить метод POST на GET или удалить значение токена из ключа — csrf_token=
С защитой реферера вы можете попытаться добавить свой домен к рефереру, например, http://site.com.yourdomain.com.
Или если есть проверка, что домен должен быть в конце реферера, можно попробовать так: http://yourdomain.com/site.com
И третье основное правило при поиске ошибок — помещать базовую полезную нагрузку во все возможные входные данные: qwerty'"<X</
И наблюдайте за отражением текста на веб-сайте. Если вы где-то увидите qwerty'" (без угловых скобок) — это может быть шанс XSS
Кроме того, найдите текст qwerty в исходном коде страницы. Используйте инструменты разработчика в браузере для этой задачи.
Полезные нагрузки могут быть отражены где угодно:

1. В параметрах тега:

<span>qwerty'"<x</span>

2. В атрибутах тега:

<a class="qwerty'"<x</">

3. В атрибутах события тега с логикой изменения местоположения:

<a onclick="location.href='qwerty'">

Здесь вы можете попробовать внедрить javascript. Например:

location.href='javascript:alert(1)'

4. Внутри тега <script>:

<script>let a = "qwerty'"<x</"<script>

Удачной охоты!