IDOR в BFF-layer: Как твой фронтенд сливает данные

Эй, бро, думаешь, что BFF-слой — это твой щит от всяких ушлых багхантеров? Ага, как мой старый роутер с паролем «admin123». IDOR (Insecure Direct Object Reference) в BFF-архитектуре — это когда твой «умный» посредник между фронтом и бэком отдаёт данные, которые ты даже не просил. Это не баг, это твой миссконфиг, который я сейчас тебе разберу. Погнали искать дырки, пока твой репорт не улетел в /dev/null.

Точка входа: Где прячется этот IDOR?

• Что вижу: Эндпоинт в BFF-слое типа /api/user-profile/12345, где ID юзера или объекта передаётся напрямую, а проверка доступа на серваке — как мой антивирус в 2005, то есть её нет.

• Как поймал: Инструмент — Burp Suite для перехвата запросов + ffuf для брута IDшек (ffuf -u http://target.com/api/user-profile/FUZZ -w id_list.txt). Метод — подмена параметров в запросах (меняем userId=12345 на userId=12346) и смотрим, что отдаёт.

• Чем пахнет: Классический IDOR с вероятностью слива данных (7/10, если BFF не делает валидацию сессии). Это как взять чужой пропуск на DEFCON — просто показываешь ID и заходи.

Чё почём: Как слить или как защитить?

• Эксплойт: Перехватываем запрос через Burp или прям в браузере меняем ID в URL. Пример:

Если в ответе JSON с данными другого юзера (телефон, почта, бабки на счету) — поздравляю, ты только что стал «админом» без прав админа. Хочешь больше? Брути дальше:

• Собирай почты, как грибы после дождя.

• Обход защиты: Если BFF проверяет сессию — ищи слабый JWT. Ломай его через jwt_tool:

• Смени userId на чужой и подставь новый токен в запрос. WAF? Пфф, энкодь ID в base64 или юзай заголовки типа X-Original-URL для обхода фильтров.

• Доказательство: Сделай скрин ответа с чужими данными. Видишь email: victim@target.com? Это не твой мейл, это твой PoC на выплату.

Векторы добивания

Если ты на баг-баунти и уже зацепил IDOR, вот три вектора для добивания:

1. Массовый слив: Автоматизируй брут IDшек через скрипт на Python с requests. Дампи базу юзеров или заказов.

2. Эскалация: Ищи эндпоинты для изменения данных (/api/update-profile/12346) и пробуй менять чужие пароли или настройки.

3. Привязка к другим баунти: Если есть доступ к заказам (/api/order/54321), проверь, можно ли отменить заказ или сменить адрес доставки на свой.

Если ты админ и не хочешь репорта на HackerOne, то:

1. Валидируй доступ к объектам на BFF-уровне: проверяй, принадлежит ли ID текущему юзеру.

2. Используй UUID вместо последовательных ID — сложнее брутить.

3. Ограничивай API токенами с минимальными правами, никаких admin: true в JWT.

План атаки (если ты в деле)

1. Сканируй API через Burp или Postman, ищи эндпоинты с ID в параметрах (/api/resource/123).

2. Подменяй ID и смотри ответ: если данные не твои — это IDOR.

3. Автоматизируй слив через скрипт и готовь репорт с PoC (видео или дамп ответов).

Советы

• Проверяй robots.txt и sitemap.xml — часто там лежат пути к /api/admin-users/list, где IDOR цветёт и пахнет.

• Если JWT в запросах — ломай через jwt_tool -I -pc role -pv admin, ищи alg: none или слабый ключ.

• Сканируй на предмет облачных метаданных (169.254.169.254), вдруг BFF крутится в AWS, и ты вытянешь ключи.

Реальный кейс: CVE и мясо

Возьмём пример из жизни: уязвимость типа CVE-2021-21351 (XWiki IDOR, просто для иллюстрации). Если BFF-слой построен на кривом фреймворке, ты можешь подменить ID и получить доступ к чужим документам. Эксплойт: прямой запрос с изменённым параметром. Ссылка на мясо: https://www.exploit-db.com/exploits/49629. Если API отдаёт чужие данные — это твой билет на payout.

IDOR в BFF — это как твой фронтенд: кричит «всё защищено», а внутри пустота. Копай глубже, не тупи, и помни: BFF — это не безопасность, это прослойка для твоих багов.