Authz-bypass через кастомные headers

Точка входа:
Что вижу: Сервак принимает кастомные заголовки (X-User-Id, X-Forwarded-For, X-Auth-Role). Админы сами намудрили middleware, и вместо нормального JWT у них — доверие к строке в header.
Как поймал: Burp + repeater + ffuf по словарю заголовков → бах, X-Admin: true и ответ уже 200.
Чем пахнет: AuthZ-bypass (вертикалочка до админа). Вероятность: жирная 9/10.

Че по чём
Эксплойт:
— Минимальный PoC:

— Или более извращённое:

→ потому что бэкенд думает: «ага, локалхост, значит доверенный».

Обход защиты:
— Если WAF душит X-Auth-* → юзай нестандартные регистры (x-auth-user, X-Auth-User, X-AUTH-USER).
— Если фильтр на ключ → бейся через дублирование (X-Role: admin + X-Role: user). В старых проксях побеждает первый или последний.
— HTTP/2 → заголовки кейс-инсенситив, а бэкенд — нет. Играешь в капслок-бинго.

Доказательство:
Запрос без хедера → 403 Forbidden. С X-Admin: 1 → 200 OK и в респонсе {"role":"admin"}. Всё, готовый скриншот PoC. Это не тест, это прямой допуск в админку.

Советы:
3 вектора для добивания:
1. Проверить X-Original-URL, X-Rewrite-URL — старье в IIS/Apache до сих пор живое.
2. Закинуть X-Forwarded-Host: internal.admin.local → может, проглотят и сделают SSRF.
3. Комбинировать X-Remote-User с SSO — случайные три буквы в хедере = вход под доменным админом.

План атаки:
1. Поднимаем wordlist кастомных заголовков (X-User, X-Auth, X-Role, X-Access-Level, X-AspNet-Version).
2. Пробуем их по методам (GET/POST) на разные эндпойнты.
3. Отмечаем, где меняется код ответа или тело.
4. Локализуем баг: если запрос с X-User: victim вытягивает чужие данные → IDOR + вертикальный bypass.
5. Докидываем PoC с красивым curl → готов багрепорт в BB.

Итог:
Authz-bypass через кастомные headers — это как студенческая общага: дверь вроде на замке, но у каждого в кармане «свой мастер-ключ» от розетки. Разрабы сами повесили ярлык “X-Admin: 1” вместо замка.