Здарова, братан. Снова я. Помнишь, как раньше мы ломали сайты через SQLi и XSS? Весело было. Но сейчас весь сок, вся мякотка — в API. Разрабы пилят микросервисы, клепают эндпоинты для мобилок и фронтенда, а про безопасность думают в последнюю очередь. Они думают, раз снаружи красивая кнопочка, то никто в потроха не полезет. Наивные.

API — это как задняя дверь в банк, которую оставили открытой, повесив табличку «Только для персонала». А у нас как раз есть универсальный пропуск — Burp Suite и прямые руки. Давай разберём, где бэкендеры чаще всего лажают и как нам на этом подняться.

Точка входа: IDOR — Insecure Direct Object Reference

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

Что я вижу: Я захожу в личный кабинет. Перехватываю запрос на получение данных моего профиля. Он выглядит так:
GET /api/v3/users/11235/profile HTTP/1.1
Host: example.com
Authorization: Bearer ey...

Цифра 11235 — это мой ID. Мой мозг пентестера тут же орёт: «А что, если…?»

Offensive-анализ и векторы атаки:
IDOR — это не просто прочитать чужие данные. Это про полный контроль.

1. Чтение чужих данных (Горизонтальное повышение привилегий):
   Просто меняем ID в запросе. Пробуем соседние, пробуем предсказуемые.

Если в ответе пришёл JSON с данными юзера 11236 — бинго. Мы можем слить всю базу пользователей.

2. Захват админки (Вертикальное повышение привилегий):
Какие ID самые вкусные? 1, 2, 100… Первые зарегистрированные пользователи часто бывают админами.

Если получили профиль админа — это уже серьёзно.

3. Изменение чужих данных:
Самый жир — когда IDOR работает не только на GET, но и на POST или PUT.

4. После этого идём на форму восстановления пароля, вводим почту hacker-controlled@evil.com и получаем полный доступ к аккаунту админа. Пиздец.

Трюк: Иногда вместо числовых ID используют UUID. .../users/a1b2c3d4-e5f6-..... Они неперебираемы. Но их часто можно найти в других местах: в ответах API, в JS-файлах на фронте, в публичных ссылках на профили. Нашёл чужой UUID — попробуй подставить.

Точка входа: Mass Assignment — Массовое присвоение

Это подарок от ленивых разрабов, которые используют фреймворки типа «взял JSON и сохранил в базу». Они не фильтруют поля, которые можно обновлять.

Что я вижу: Я перехватываю запрос на редактирование своего профиля.
PUT /api/v1/me HTTP/1.1
Host: example.com
Authorization: Bearer ey...
Content-Type: application/json

{"first_name": "John", "last_name": "Doe"}

Мозг пентестера: «А какие ещё поля есть в модели User на бэкенде? Наверняка что-то вроде isAdmin, role, balance, is_premium…»

Offensive-анализ и векторы атаки:
Наша задача — угадать или найти скрытые поля и подсунуть их в запрос.

1. Получаем права админа:
   Самый очевидный и действенный пейлоад.

Часто прокатывают варианты: is_admin, admin, user_role, access_level. Просто добавляем их в JSON. Если после этого в ответе или в функционале появляются админские фичи — мы внутри.

2. Набиваем карманы:
Если это интернет-магазин или сервис с внутренним балансом.

Трюк: Как угадать имена полей?

• Регистрация: Посмотри на JSON, который возвращается после регистрации нового юзера. Часто API по неосторожности возвращает весь объект пользователя, включая поля role или isAdmin со значениями по умолчанию ("user", false).
• Excessive Data Exposure: Иногда в ответе на GET /api/v1/me прилетает куча лишних данных, которые фронтенд не показывает, но мы-то в Burp всё видим.
• Документация: Ищи на сайте или в репозиториях GitHub файлы swagger.json, openapi.yaml. Это полная карта API со всеми моделями и полями.

Прочие радости: Краткий список

• Excessive Data Exposure (Избыточная отдача данных): API возвращает в JSON больше данных, чем нужно фронту. Например, в профиле пользователя может быть хеш пароля, внутренние заметки, токен для сброса. Всегда смотри RAW-ответ, а не то, что показывает браузер.
• Lack of Rate Limiting (Отсутствие лимитов на запросы): На эндпоинте POST /api/login или POST /api/reset_password нет защиты от брутфорса. Можно перебирать пароли, логины, коды из SMS/Email. Берём ffuf и вперёд:

• BOLA (Broken Object Level Authorization): Это просто новое модное название для IDOR. Суть та же. Видишь объект с ID — попробуй чужой.

API — это дикий запад. Разработчики несутся вперёд, а мы, как старые ковбои, идём по их следам и собираем золото, которое они роняют из дырявых карманов. Главное — не верить тому, что видишь на красивом фронтенде. Вся правда — в сырых запросах.

Советы

1. Изучи эндпоинты для админов: Попробуй подставить в URL /admin/, /api/admin/, /management/. Иногда на них просто забывают повесить авторизацию, и можно зайти, как к себе домой. GET /api/v1/admin/users.
2. Версионирование API: Если ты видишь в URL /api/v2/, всегда попробуй /api/v1/. Часто старые версии API оставляют работать для обратной совместимости, но забывают на них накатить патчи безопасности. v1 может быть дырявой, как решето.
3. HTTP Verb Tampering (Манипуляция глаголами): Эндпоинт GET /api/users/1 может быть защищён, а вот HEAD /api/users/1 — нет, и он может слить заголовки с чувствительной инфой. Или DELETE /api/users/1 может сработать вообще без авторизации. Проверяй все методы: GET, POST, PUT, DELETE, PATCH, OPTIONS.
4. GraphQL: Если видишь, что API использует GraphQL (запросы типа {"query": "..."}), первым делом проверь, не включена ли интроспекция. Если да — ты можешь выкачать всю схему API и увидеть все возможные запросы и мутации. Это как получить исходники бэкенда.
5. Цепочки уязвимостей: Найденный IDOR может быть бесполезен сам по себе, если ты не знаешь ID других юзеров. Но если ты нашёл другую уязвимость, например, утечку данных (Excessive Data Exposure), которая сливает список ID, то ты можешь связать их в одну мощную атаку. Сначала слил ID, потом через IDOR захватил аккаунты.

На этом все. Всем хорошего дня!