Белый хакер с нуля: как взламывать сайты и получать за это благодарность, а не повестку
Ты хочешь быть хакером, но не жить в подвале и не прятаться от органов? Поздравляем, тебе — в белые! Это когда ты не «ломаешь», а «помогаешь находить уязвимости». Такая себе цифровая санитарная проверка, но со скиллом.
Кто такой белый хакер?
Это специалист, который ищет дыры в системах до того, как туда полезет кто-то не очень вежливый. Он не злодей — он «айтишный доктор». Видит баг — лечит. А иногда ещё и получает за это деньги. Да-да, честно.
С чего начать:
1. Учишься на чужих ошибках (и немного на своих)Читаешь про OWASP Top 10 — это как «10 смертных грехов сайтов». Все там: SQL-инъекции, XSS, плохие пароли и «бабушка админом».
2. Знакомишься с инструментами
Burp Suite, Nmap, Metasploit — твои новые друзья. Они не пекут пирожки, но помогут найти, где сайт открыл лишнюю дверь.
3. Практикуешься на полигонах, а не на соседнем магазине
Hack The Box, TryHackMe, WebGoat — это легальные песочницы, где можно ломать всё подряд. Главное — не лезь туда, где тебя не ждали. Этично — значит по правилам.
4. Регистрируешься на платформах: HackerOne, Bugcrowd, YesWeHack
Это как биржа для белых хакеров. Ты ищешь уязвимости — компании платят. Главное — быть аккуратным и вежливым, ты ведь не шпион.
Что важно помнить:
- Ты не Джеймс Бонд. Не нужно делать это ради адреналина. Лучше ради знаний и пользы.
- Не пиши «Я вас взломал» в отчётах. Пиши «обнаружена потенциальная уязвимость». Вежливо = профессионально.
- Ошибки — нормально. Главное — учиться и не повторять их на продакшене большого банка.
Белый хакер — это не про понты, а про пользу. Ты как электрик в мире IT: если делаешь всё правильно, никто не замечает, но если нет — всё сразу начинает гореть.
Топ фейлы белых хакеров: учись на чужих ошибках, пока твой ноут не изъяли как вещественное
Белый хакинг — это круто: ты как спецназ, только вместо гранат у тебя Burp Suite. Но даже тут бывают фейлы, и некоторые из них достойны отдельной грустной песни на укулеле.
1. «Нашёл уязвимость»... только не у тех
Начинающий хакер сканит всё подряд, находит дыру — и сразу в Telegram:
Вывод: без официального разрешения — это уже не белый хакинг. Это сам себе проблема.
2. Запустил сканер на прод — и уронил всё
Nmap, Nikto, sqlmap... Казалось бы, просто проверка.
Но если без мозгов и с флажками по максимуму — можно «проверить» сайт так, что от него останется только логотип и боль в глазах админа.
Вывод: сначала читай документацию. Потом читай ещё раз. Потом запускай.
3. «Я отправил багрепорт, почему никто не отвечает?!»
Письмо в багбаунти-платформу на уровне:
А там сидит тимлид, который видит 200 таких писем в день. Ни ссылки, ни скриншота, ни доказательств — просто XSS по настроению.
Вывод: хороший отчёт — это половина успеха. Вторая — быть вежливым.
4. Уязвимость есть, но баллы не дали
Нашёл баг. Счастье. Празднуешь. Отправляешь.
А тебе:
Вывод: сначала ищем в репортах, потом — в системе. Даже баги иногда бывают заняты.
5. Хочу как в кино: нажал enter — и ты в системе
Ожидание: взлом за 30 секунд под музыку.
Реальность: 4 часа смотришь в HTML-код и радуешься, если у кого-то cookie не по флагу HttpOnly.
Вывод: белый хакинг — это не магия. Это рутинная, аккуратная и мозговитая работа. С бонусом в виде поощрения и хорошей кармы.
Фейлы — это не страшно. Главное — чтобы они были на тестовой площадке, а не в реальной жизни. Учи основы, практикуйся в песочницах, и помни: главное оружие хакера — не ноутбук, а здравый смысл.
Как написать отчёт о баге: искусство объяснить проблему так, чтобы не удалить письмо сразуТы нашёл уязвимость. Сердце стучит, глаза блестят, кофе в кружке наконец остыл. Но вместо «Ого, какой вы молодец!» тебе отвечают через 6 дней:
Нет. Просто ты плохо написал. Давай разберёмся, как писать баг-репорт, который не хочется закрыть сразу.
1. Структура — это половина успеха
Как нормальный бутерброд: снизу хлеб, потом сыр, потом огурчик. Никаких сюрпризов.Название бага — коротко и понятно:
Описание — что именно не так, куда нажать, что взорвалось.
Шаги воспроизведения — как воспроизвести баг. Прямо как рецепт:
- Зайти в профиль
- Вставить вот этот payload
- Обновить страницу
- Увидеть, как алерт мигает красивее новогодней гирлянды
Пейлоады, параметры запроса, ссылки — не жадничай, выкладывай всё.
2. Проверь сам, прежде чем отправлять
Ты не доставщик багов, ты их исследователь. Проверь:- точно ли это не фича?
- работает ли без авторизации?
- кто может воспроизвести: только ты или любой школьник с Wi-Fi?
3. Будь вежлив, даже если нашёл дыру размером с автобус
«У вас всё сломано, позор!»«Здравствуйте! Обнаружил потенциальную XSS-уязвимость. Прилагаю подробности ниже.»
Это как с резюме — даже если ты золото, без нормального оформления тебя не заметят.
4. Не делай вот так:
- «У вас баг, сам ищите где».
- «Нашёл XSS. Где мои деньги?»
- Отправил без разрешения в программу (и ещё в 03:00 ночи).
- Писал всё КАПСОМ.
- Приложил скриншот в .rar с паролем. Пароль, конечно, нигде не указал.
Бонус: волшебная фраза
Мягко, уважительно, и сразу на голову выше половины участников платформы.
Баг-репорт — это не просто «нашёл баг». Это показал, объяснил, помог исправить. Делай как профи, и мир багбаунти тебе улыбнётся. Иногда даже с деньгами.
ТОП-5 уязвимостей, за которые багбаунти платит не “спасибо”, а вполне реальные цифры
Ты можешь быть хоть трижды талантливым, но если ищешь баги в разделе “Контакты” и радуешься 404-й, то максимум что ты получишь — сочувствие. А вот если знаешь, что искать — уже путь к награде.
1. Stored XSS (он же “сам себе укол”)
Что это: ты вводишь вредный скрипт, он сохраняется, и при открытии страницы у всех всё шевелится и мигает. Иногда — даже пароли крадёт.Почему платят: XSS — это классика. Если в чувствительном месте (например, в админке) — можешь рассчитывать на приличную сумму.
Сколько: от $100 до $3000+ в зависимости от контекста.
2. IDOR (Insecure Direct Object Reference)
Что это: ты меняешь цифру в URL, и внезапно видишь чужие заказы, файлы или личные данные.Почему платят: IDOR — тихий убийца. Прост в эксплуатации, опасен, как тёща с доступом к Wi-Fi.Было: site.com/user/142
Стало: site.com/user/143
А это уже не ты
Сколько: $500–$5000+ (особенно если данные чувствительные).
3. Broken Access Control
Что это: система говорит «тебе нельзя», но ты всё равно проходишь. Как будто турникет пищит, но пропускает.Почему платят: это не баг — это прямо взлом. Если ты можешь стать админом без приглашения, то ты уже почти начальник ИБ-отдела.
Сколько: $1000–$10 000 (и это без преувеличений).
4. Sensitive Data Exposure
Что это: где-то в логах, API или ответах сервера внезапно торчит чужой email, токен, номер карты или пароль в открытом виде.Почему платят: потому что никто не любит, когда токены API лежат на виду. Особенно если это токен от облака с базой пользователей.
Сколько: $300–$5000+
5. Business Logic Bypass
Что это: баг не технический, а логический. Например — ты применяешь купон 10 раз, получаешь товар бесплатно, или обнуляешь цену через DevTools.Почему платят: такие уязвимости часто не ловятся сканерами — ты их находишь головой. А значит — ценятся особенно.
Сколько: зависит от наглости бага. От $500 до «можно уже откладывать на отпуск».
Бонус-урок:
Баг, который приносит деньги — это не просто “сломал”, а “сломал так, что это реально опасно”.
Контекст — решает.
XSS в комментариях к рецепту борща — смешно.
XSS в админке банка — вот тут уже серьёзно.
Уязвимость — это не просто баг. Это билет в мир «получил награду, сделал добро, и не нарушил закон». Главное — уважай правила, пиши чётко, и помни: самый ценный инструмент — твоя голова, а не Kali Linux.
Окей, залетаем с самого начала — любой багбаунти, как ни крути, начинается с поиска сабдоменов.
Хочешь баг? Найди, куда вообще стучаться. Без сабов ты не хакер, ты философ.
Разложим по MRZLK-стайлу, чётко и по фактам
Сабдомен — твой первый баг в зачатке
1. Сначала ищем — пассивка, без шума
Тулзы:- subfinder — быстро, чисто, красиво
subfinder -d target.com -silent -o subfinder.txt
- assetfinder — олд, но рабочий
assetfinder --subs-only target.com >> subs.txt
- amass (в пассиве) — забирает, что другим не по зубам
amass enum -passive -d target.com -o amass.txt
Плюс:
crt.sh, chaos dataset, rapiddns.io, urlscan.io — гугли, копай руками, сливай что видишь.
Сборка:
cat *.txt | sort -u > all-subs.txt
2. Живые или мёртвые — проверяем тихо
Используем:
- dnsx — проверка DNS
dnsx -l all-subs.txt -o resolved.txt
- httpx — онлайн ли вебка
cat resolved.txt | httpx -silent -o alive.txt
Без флуда, без банов. Никаких 1000 запросов в секунду. Всё на chill.
3. Глубже — лезем в архивы и коды
Собираем данные:
waybackurls target.com > urls.txt
gau target.com >> urls.txt
GitHub: ищи забытые сабы, конфиги, ключи
– руками через поиски или скриптами типа github-subdomains
4. Profit loop — от сабов к баунти
Реальный расклад:
- Нашёл старый staging. Зашёл — open redirect.
- Увидел забытый api.dev. Там токен.
- Поймал test-login. Пошёл пароль спрей — бах.
Багов нет без сабов. Это аксиома.
Не нашёл саб — не нашёл дверь. Всё остальное — фантазии.
Финалочка
Любой багбаунти начинается с сабов.Не с Burp, не с эксплойта, не с фуззинга. С поиска точек входа.
Чисто работаешь — живёшь долго
VPN, прокси, лимиты, голова — всё включай.
Советы для ТРУ:
Если ты до сих пор радуешься, найдя open Jenkins без auth — ты не пентестер, ты археолог.
Пока ты мечешь свои sqlmap -u по полям уязвимого добра, нормальные ребята уже собирают баги в GraphQL, стучат через кастомные protobuf API и рвут supply chain с такой скоростью, что у продуктовой команды начинается паника быстрее, чем у аналитика при слове "логов нет".
Вендоры шлют патчи, разработчики шлют тебя, а заказчики хотят чтоб ты "нашёл все баги за сутки, но не сильно портил боевую". И ты сидишь, как шаман, с burp-экспортом, где 400 строк XML, и думаешь: "А может ну его, стать тимлидом и страдать за зарплату, а не просто так?"
Кто шарит — тот уже с вечера гоняет свои yara по очередному RCE в каком-нибудь IoT-пылесосе, пока ты пытаешься объяснить джуну, что nmap -A — не substitute for brains.
Пентест в 2025-м — это не "сломал — и ушёл". Это когда ты зашёл через CI/CD, а вышел через логистику и сидишь в багбаунти-программе с новым паспортом.
#redteam #pentest #infosec #mrzlkстайл #ничегосвятого
Говорим про WebSocket — хочешь обойти CSRF? Используй WebSocket hijacking. Когда у тебя уже в руках access token, а в ответе на запрос WebSocket нет CORS, ты спокойно можешь подменить заголовки и повлиять на сессию, даже если в системе есть защита от CSRF. Важный момент: проверяй origin и accept-language — эти флаги могут быть твоими друзьями, если сервер доверяет этим заголовкам.
XSS через WebSockets? Да, это возможно. Ты можешь атаковать через injected WebSocket messages. Слушай соединение через WebSocket Proxy и подменяй данные, передаваемые в WebSocket-сессиях. Этот метод работает как свисток, если сервер не фильтрует данные перед их обработкой.
Системы с малым количеством журналов? Используй Kernel Panic для скрытного воздействия. Когда не хватает логов и стандартной информации в файловой системе, можно попробовать exfiltrate данные через kernel-level payloads, обходя защиту. Пример: перехват сетевых пакетов с BPF (Berkeley Packet Filter) — теперь у тебя есть доступ к реальному сетевому трафику и интерфейсам системы, но тебе не нужно полагаться на обычные логи.
RCE через ImageMagick? Старый добрый способ не ушёл. Пробивай через GIFs и SVG. Даже если сервер сам по себе защищён, возможно его окружение в виде библиотеки, позволяющей работать с изображениями, не так уж крепко защищено. Сгенерируй evil image payload и закинь в тот же endpoint. Бывает, что сервер даже не проверяет Content-Type, и ты можешь получить реверсную оболочку.
Приватные файлы? Обрабатывай race condition. Доступ к файлам не всегда ограничен, если ты не успел пробить флаг, но можешь использовать timing attack. Ищите моменты, когда система использует временные файлы, и ломайте их через symlink-атаки. Стандартная уязвимость в Linux при доступе через /tmp или /var/tmp будет твоей настольной книгой для пробоя таких багов.
Если статья наберет лайков столько же сколько светит ГАСАНОВУ, то я продолжу это путешествие по расписанию и с каждым разом всё будет веселее и веселее )
Последнее редактирование:
