SSRF и IDOR

Сначала авторизация: это вскрытие глазами защитника

Всё ниже предполагает подписанный договор с явно очерченной областью — намеренно уязвимый стенд, CTF, твоё собственное приложение или программу bug-bounty с целью в области. Нацелить серверную функцию запросов на чужой облачный metadata-эндпоинт или перебирать id объектов в приложении, на которое у тебя нет авторизации, — это несанкционированный доступ в большинстве юрисдикций, без вариантов. Прочесть чужую запись — нарушение приватности, даже если ты «только посмотрел». Мы изучаем рассуждения атакующего по одной причине: нельзя надёжно закрыть класс уязвимостей, который понимаешь лишь как строку в чек-листе. Читай это как вскрытие, которое защитник проводит над собственным кодом, — учась видеть запрос и SQL-запрос так, как их видит атакующий, чтобы контроль оказался в проекте до того, как баг уедет в прод. Никаких готовых пейлоадов — только механизм.

SSRF: сервер как сбитый с толку посредник

Server-side request forgery возникает, когда приложение берёт URL (или хост, или IP), на который влияет пользователь, и делает по нему исходящий запрос — функции «загрузи эту картинку», «импортируй из этого вебхука», «покажи превью этой ссылки», «провалидируй этот RSS-фид». Ввод атакующего никогда не достигает внутренней цели напрямую — вместо этого сервер обманом заставляют до неё дотянуться. Это классический сбитый с толку посредник (confused deputy): у сервера есть привилегии и сетевая позиция, которых нет у атакующего — он сидит внутри VPC, резолвит внутренний DNS, держит IAM-роль, — и атакующий заимствует всё это, выбирая, куда сервер направит запрос.

У механизма две составляющие. Во-первых, назначение запроса под влиянием атакующего, и сервер не ограничивает его известным-хорошим множеством. Во-вторых, сеть, в которой живёт сервер, содержит нечто ценное, до чего атакующий не дотянется снаружи: облачный metadata-сервис инстанса, внутреннюю админ-панель на приватном IP, базу, принимающую соединения только с прикладного слоя, K8s API на cluster-IP. Хрестоматийный приз — облачный metadata-эндпоинт по link-local адресу 169.254.169.254, который на неправильно настроенном инстансе раздаёт IAM-учётки машины всякому, кто спросит изнутри хоста. SSRF дотягивается до него, потому что запрос теперь исходит изнутри хоста.

Рассуждение атакующего — серия проб. Следует ли функция за редиректами (чтобы allowlist-хост 302-редиректнул на внутренний)? Резолвит ли она DNS в момент запроса (чтобы имя, резолвящееся в публичный IP при валидации, перерезолвилось в 127.0.0.1 при запросе — гонка DNS-rebinding)? Принимает ли схемы кроме http, вроде file://, gopher:// или dict://, превращающие запрос в чтение файла или сырую запись в Redis? Каждое «да» — ещё один обход наивной защиты. Поэтому SSRF и попал в OWASP Top 10 голосованием практиков, несмотря на скудные исторические данные: облачные архитектуры сделали радиус поражения огромным — одна функция запроса может стать полной компрометацией облачного аккаунта.

IDOR: отсутствующая проверка владельца

Insecure Direct Object Reference — это продакшен-лицо Broken Access Control. Сервер выставляет ссылку на внутренний объект — чаще всего id строки БД в URL вроде /api/orders/7741, — использует это присланное клиентом значение для поиска объекта и никогда не проверяет, что вызывающий вправе видеть именно этот объект. Запрос — SELECT … WHERE id = ?, когда должен был быть SELECT … WHERE id = ? AND owner_id = ?. «Эксплойт» атакующего — инкремент целого числа. Ни пейлоада, ни особого инструмента: валидная сессия плюс угадываемый id — и это весь штурм.

Ключевое переосмысление: IDOR — это авторизация, а не аутентификация. Атакующий полностью залогинен как он сам — в этом и суть. Аутентификация спрашивает «кто ты?», и сессия отвечает верно. Авторизация спрашивает «вправе ли ты трогать этот объект?», а уязвимый код её вовсе не задаёт — он молча считает, что валидная сессия даёт право на любой id, который ты назовёшь. Ссылки на объекты утекают постоянно — в URL, логах, заголовках referer, расшаренных ссылках, прошлых ответах API, — поэтому «сделать id случайными UUID» лишь повышает стоимость угадывания; недостающую проверку это не добавляет. Вот зрелая ловушка, которой надо избежать: неугадываемые идентификаторы — это обфускация, а не контроль доступа.

Один корень, зеркальная форма

Поставь SSRF и IDOR рядом — и симметрия и есть урок. В обоих сервер берёт значение от клиента и действует по нему, не контролируя подразумеваемую границу. IDOR доверяет ссылке на объект как «тебе можно прочитать этот объект». SSRF доверяет URL как «тебе можно сходить за этим ресурсом». Оба подменяют непроверенным клиентским значением серверное решение об авторизации. Таблица делает параллель явной.

Как защитник закрывает оба

Для IDOR фикс структурный, не косметический: проверяй авторизацию на сервере по самому объекту и действию, каждый раз, вычисляя её из серверного состояния сессии — никогда не выводя из скрытого UI-элемента или присланного клиентом claim’а. В запросе это значит ограничение по владельцу (WHERE id = ? AND owner_id = ?) или явная проверка политики до возврата строки. Централизуй её, чтобы новый эндпоинт не мог про неё забыть, и сделай авторизацию на уровне объекта тем умолчанием, которое наследует каждый обработчик.

Для SSRF защита слоистая, потому что ни один контроль не достаточен сам по себе. Ограничь назначение allowlist’ом разрешённых хостов/схем, резолвь имя хоста и валидируй резолвленный IP против заблокированных диапазонов (link-local 169.254.0.0/16, loopback, приватные RFC-1918, metadata-IP облака) и перепроверяй после каждого редиректа — валидация одной только строки проигрывает DNS-rebinding и редиректам. Затем считай, что контроль однажды откажет, и укрепи саму цель: требуй metadata-сервис с сессионными токенами (уровня IMDSv2, который блокирует простой GET, на котором держится классический SSRF), дай инстансу минимум нужных IAM-привилегий и поставь egress-правила файрвола, чтобы прикладной слой попросту не мог открывать произвольные исходящие соединения. Повторяющийся зрелый рефлекс для обоих багов один: отказывай по умолчанию, проверяй границу на сервере и никогда не позволяй непроверенному клиентскому значению заменять решение об авторизации.