Собеседование AppSec инженер: почему вопрос про SSRF во внутреннем API ломает кандидатов

На последнем раунде найма в security-команду продуктовой компании я задавал десяти финалистам один вопрос: «Объясните, как вы эксплуатируете SSRF во внутреннем API приложения на AWS — от первого запроса до получения доступа к инфраструктуре». Семеро начинали одинаково: «SSRF — это Server-Side Request Forgery, номер A10 в OWASP Top 10, когда сервер делает запрос по URL от пользователя…» — и через тридцать секунд замолкали. Трое описали полную цепочку до кражи IAM-credentials через облачный metadata-сервис. Офферы получили только эти трое.

Дальше разбираю, что разделяет две группы и как попасть во вторую.

Что слышит интервьюер, когда кандидат цитирует OWASP Top 10 на собеседовании

OWASP Top 10 — рейтинг десяти самых критичных категорий уязвимостей веб-приложений. Обновляется раз в несколько лет, последняя версия — 2021. SSRF (Server-Side Request Forgery — подделка запросов на стороне сервера) сидит на позиции A10:2021 и попала в список по результатам голосования security-сообщества. Если вы только начинаете разбираться в AppSec — запомните: OWASP Top 10 создан для awareness (осведомлённости), а не как руководство к действию. Он говорит «SSRF — проблема», но не говорит «вот как я ломаю конкретный API через SSRF».

Когда кандидат на собеседовании AppSec инженера начинает с определения из OWASP, интервьюер слышит не ответ, а его отсутствие. Определение — входной билет, уровень «погуглил вчера». Типичный слабый ответ:

«SSRF — это когда злоумышленник заставляет сервер сделать запрос на внутренний ресурс. Нужно валидировать пользовательский ввод и использовать allowlist.»

А вот что ожидает интервьюер:

«Нахожу параметр, принимающий URL. Подставляю свой домен — проверяю, приходит ли callback. Если приходит — подставляю адрес metadata-сервиса 169.254.169.254 и смотрю, вернёт ли сервер IAM-роль. Если endpoint фильтрует localhost и 169.254 — пробую decimal-кодировку, IPv6, redirect через свой сервер. Для защиты одного allowlist мало: нужно резолвить DNS до проверки, блокировать egress на сетевом уровне и переводить EC2 на IMDSv2.»

Разница не в эрудиции. Первый кандидат описывает категорию, второй описывает свои действия. На вопросах на собеседовании AppSec проверяют операционный навык: можете ли вы взять конкретный endpoint, пройти от обнаружения до компрометации и объяснить защиту.

Когда кандидат оперирует только списком — это сигнал, что практического опыта эксплуатации уязвимостей веб-приложений нет.

SSRF уязвимость внутренний API: анатомия вопроса

Бизнес-логика атаки: зачем злоумышленнику SSRF

Перед разбором техники — мотивация. Интервьюеры часто начинают именно с вопроса «а зачем?». Кандидат, который не может объяснить impact на бизнес-языке, теряет баллы даже при безупречной технике.

SSRF превращает сервер приложения в прокси-агент атакующего внутри сети. Сервер уже прошёл firewall, находится в доверенной зоне и имеет сетевой доступ к внутренней инфраструктуре API, недоступной из интернета. Атакующий не взламывает периметр — он заставляет легитимный сервер работать от своего имени.

Три главные цели SSRF в облачном окружении:

Кража облачных credentials. На AWS, GCP, Azure у каждой виртуальной машины есть metadata-сервис по адресу 169.254.169.254 — локальный endpoint, доступный только изнутри инстанса. Он отдаёт временные credentials с правами IAM-роли (Identity and Access Management — система управления доступом в облаке). Успешная SSRF к этому адресу = ключи от облачной инфраструктуры.

Доступ к внутренним API. Микросервисная архитектура — это десятки сервисов, которые общаются друг с другом без аутентификации или с минимальной проверкой. SSRF открывает прямой доступ к ним.

Разведка внутренней сети. Через SSRF можно определить запущенные порты и сервисы на внутренних адресах — reconnaissance, невозможная снаружи.

Если вы встречаете MITRE ATT&CK впервые — это открытая база тактик и техник атак, где каждой технике присвоен T-код (идентификатор). Результат успешной SSRF описывается через несколько техник: кража credentials из metadata-сервиса — Cloud Instance Metadata API (T1552.005, тактика Credential Access); использование украденных ключей — Valid Accounts: Cloud Accounts (T1078.004, тактики Initial Access и Privilege Escalation). На собеседовании знание T-кодов — бонус, но главное — понимать саму цепочку.

Самый известный пример — атака на Capital One в 2019 году. По данным APIsec и публичных разборов, злоумышленник через SSRF в веб-приложении на AWS обратился к metadata-сервису, получил IAM-credentials и скомпрометировал данные порядка 100 миллионов клиентов. Одна уязвимость — и вся облачная инфраструктура открыта.

Не абстрактная статистика. Именно поэтому на каждом собеседовании AppSec инженера (application security engineer) вопрос про SSRF будет обязательным.

Цепочка эксплуатации от запроса до облачных credentials

На собеседовании от вас ждут пошаговое описание атаки. Каждый шаг — «галочка», которую интервьюер мысленно ставит.

Шаг 1 — найти параметр, принимающий URL. Типичные кандидаты на уязвимость: endpoint импорта данных по ссылке, генерация PDF из внешнего ресурса, webhook-регистрация, загрузка аватара по URL, preview ссылки в чате. В Burp Suite (инструмент для перехвата и анализа HTTP-запросов) открываете Proxy → HTTP history и ищете параметры url=, callback=, redirect=, src=. Видите полный URL, начинающийся на http:// или https:// — потенциальная точка входа.

Шаг 2 — подтвердить, что сервер делает запрос. Подставляете URL своего сервера (или используете Burp Collaborator — встроенный сервис для out-of-band детекции). На ваш сервер приходит HTTP-запрос от IP целевого приложения — подтверждено: сервер фетчит URL без предварительной проверки.

Шаг 3 — обратиться к внутренним адресам. Подставляете адрес metadata-сервиса:

POST /api/v1/fetch-preview HTTP/1.1
Content-Type: application/json

{"url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/"}

Если ответ содержит имя IAM-роли (например, ec2-app-role), следующий запрос к /latest/meta-data/iam/security-credentials/ec2-app-role вернёт AccessKeyId, SecretAccessKey и Token — временные credentials с правами IAM-роли сервера.

Шаг 4 — оценить масштаб доступа. Через AWS CLI (aws sts get-caller-identity) подставляете украденные ключи и проверяете, к каким сервисам есть доступ: S3-бакеты с данными клиентов, RDS-базы, Lambda-функции. На этом шаге SSRF превращается из «прочитал metadata» в «полная компрометация облачного аккаунта».

Шаг 5 — объяснить impact. На собеседовании недостаточно показать технику. Если IAM-роль имеет s3:* — атакующий выгрузит все данные клиентов. Если есть права на RDS — прямой доступ к базе. Это разница между отчётом «нашёл SSRF» и отчётом «компрометация PII 2 миллионов пользователей».

Кандидат, прошедший все пять шагов и объяснивший на каждом, что он проверяет и почему, — это уровень, который приводит к офферу. Именно этот навык отличает реального Application Security Engineer от человека, выучившего определения.

SSRF защита и эксплуатация: bypass-техники на собеседовании

Обход фильтров через кодировки и парсинг URL

После описания базовой цепочки интервьюер задаёт follow-up: «А если endpoint фильтрует 169.254.169.254 и localhost?». Это проверка глубины — знаете ли вы, что строковая фильтрация обходится.

Кандидат, который отвечает «тогда не получится», — проваливает вопрос. Практик знает: один и тот же IP-адрес записывается десятками способов, а фильтр проверяет строку, не реальный адрес назначения:

# Decimal: 127.0.0.1 = 2130706433
http://2130706433/internal
# Octal: 127.0.0.1 = 0177.0.0.1
http://0177.0.0.1/admin
# Hex: 127.0.0.1 = 0x7f000001
http://0x7f000001/metrics
# IPv6 loopback
http://[::1]/admin
# @ credential injection: парсер видит trusted.com, HTTP-клиент идёт на internal
http://trusted.com@internal-service/path

Каждая запись — один адрес, но blacklist-фильтр (чёрный список — блокировка известных «плохих» строковых значений) видит разные строки и пропускает запрос. Корневая причина большинства bypass’ов — URL parsing inconsistency: расхождение между тем, что видит валидатор, и тем, куда реально уходит запрос.

Ещё одна техника — redirect через свой сервер. Атакующий регистрирует домен, который отвечает HTTP 302-редиректом на http://169.254.169.254/.... Приложение проверяет исходный URL (не в blacklist) и делает запрос. HTTP-клиент следует за редиректом и попадает на metadata-сервис. С помощью ffuf (фаззер HTTP-запросов) можно автоматизировать перебор bypass-вариантов для конкретного фильтра.

Отсюда ключевой принцип, который нужно озвучить на собеседовании: проверять нужно не строку URL, а IP-адрес после DNS-резолвинга.

Защита от SSRF — что ожидает услышать интервьюер

На собеседовании AppSec инженера вопрос про защиту — обязательная часть. Кандидат, который умеет ломать, но не умеет защищать, — пентестер (red team), а не AppSec. Вот чек-лист, который покажет зрелость:

Allowlist вместо blacklist. Если приложение обращается к внешним URL — определите конкретный список разрешённых доменов. Allowlist (белый список) блокирует всё, кроме явно одобренного. Blacklist не работает, потому что невозможно перечислить все способы кодировки внутреннего адреса. Я видел фильтры на 200 строк регулярок — и всё равно находился обход.

DNS resolution до проверки. Правильный порядок: (1) получить URL от пользователя, (2) резолвить DNS, (3) убедиться, что IP не попадает в приватные диапазоны (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16), (4) только после этого выполнить запрос. Это закрывает bypass через DNS rebinding и redirect-цепочки.

Egress-фильтрация на сетевом уровне. Даже если код уязвим — firewall rules на уровне VPC (Virtual Private Cloud — изолированная виртуальная сеть в облаке) запрещают серверу обращаться к metadata-сервису. На AWS это Security Groups и Network ACLs, ограничивающие исходящий трафик.

IMDSv2 на AWS. Вторая версия Instance Metadata Service требует PUT-запрос с получением токена перед доступом к metadata. Простой SSRF через GET не сработает: IMDSv2 требует сначала отправить PUT /latest/api/token с заголовком X-aws-ec2-metadata-token-ttl-seconds. Не каждая SSRF позволяет контролировать метод и заголовки запроса.

Сетевая сегментация. Frontend-сервис не должен иметь доступ к базе данных напрямую. Принцип минимальных привилегий применяется не только к пользователям, но и к сетевым связям между сервисами.

Хороший ответ покрывает все пять уровней. Отличный добавляет: «одного уровня недостаточно — нужна defense in depth (эшелонированная защита), потому что каждый отдельный контроль обходится». Это показывает, что кандидат понимает реальную практику защиты, а не пересказывает чек-лист.

Практические навыки пентестера API: делай раз, делай два, делай три

Эта секция — для самостоятельной подготовки к собеседованию и тестовому заданию AppSec инженера. Все шаги выполняются в безопасной лабораторной среде.

Предпосылки: Burp Suite Community Edition (бесплатная), установленный curl, тестовое приложение с SSRF. Подойдёт PortSwigger Web Security Academy — бесплатные лабы по SSRF с пошаговым разбором. Начните с них, если раньше SSRF руками не трогали.

Делай раз: найди URL-параметр. Запустите Burp Suite и настройте браузер на работу через прокси (127.0.0.1:8080). Пройдите по функциям тестового приложения. В Burp → Proxy → HTTP history отфильтруйте запросы по ключевым словам: url, callback, redirect, src, dest. Ищите параметры с полным URL (начинается на http://). Ожидаемый результат: найден хотя бы один endpoint, принимающий URL в параметре.

Делай два: подтверди SSRF. Отправьте найденный запрос в Burp Repeater (правый клик → Send to Repeater). Замените URL на адрес, который вы контролируете — например, бесплатный webhook.site, который покажет входящие HTTP-запросы:

curl -X POST http://target-app/api/fetch \
  -H "Content-Type: application/json" \
  -d '{"url": "https://webhook.site/your-unique-id"}'
# Формат запроса (JSON/form/query) зависит от конкретного приложения — проверяйте Content-Type в оригинальном запросе через Burp

Ожидаемый результат: на webhook.site появился входящий запрос от IP целевого приложения (не вашего). Это подтверждает, что сервер отправляет запрос по пользовательскому URL. Запрос не пришёл — возможно, приложение валидирует домен или протокол; пробуйте другие параметры.

Делай три: проверь доступ к внутренним ресурсам. В Burp Repeater подставьте http://127.0.0.1/ и наблюдайте ответ. Затем попробуйте http://169.254.169.254/latest/meta-data/. Ответ содержит данные (HTML, JSON, имя IAM-роли) — SSRF подтверждена и эксплуатируема. Ответ пустой или с ошибкой — пробуйте bypass-техники: decimal-кодировку (http://2130706433/), IPv6 (http://[::1]/). Зафиксируйте каждый шаг: какой запрос отправили, какой ответ получили, какой потенциальный ущерб. Этот формат документирования — то, что проверяют на тестовых заданиях.

Для тех, кто выясняет, как стать AppSec инженером, и строит карьеру в ИБ AppSec — практический опыт с инструментами фаззинга (ffuf для перебора URL-параметров, gopherus для генерации payload’ов через gopher-протокол) заметно усиливает ответ на собеседовании. Фаззер — не замена пониманию, но с ним вы покрываете больше вариантов за меньшее время.

Подготовка к собеседованию по безопасности: чек-лист по SSRF-блоку

Вопрос про SSRF на собеседовании по безопасности приложений почти никогда не приходит одиночным. За основным вопросом следуют уточняющие. Типичные follow-up и ожидаемые ответы:

Минимальный набор для уверенного ответа по SSRF-блоку:

1. Описать полную цепочку эксплуатации (пять шагов из раздела выше)
2. Назвать 3-4 техники bypass фильтров с конкретными примерами
3. Перечислить 5 уровней защиты — от кода до сети
4. Объяснить разницу между обычной и blind SSRF
5. Рассказать, как IMDSv2 меняет ситуацию для атакующего
6. Озвучить impact на бизнес-языке, а не только техническим

По данным IBM X-Force Threat Intelligence Index 2025, атаки с использованием действительных учётных данных (valid credentials) выросли на 71% за 2024 год. SSRF во внутреннем API — один из ключевых способов эти credentials получить. Verizon DBIR 2025 подтверждает: 38% утечек данных связаны с кражей credentials. Интервьюеры в продуктовых компаниях знают эту статистику и ищут кандидатов, понимающих полную цепочку от SSRF до компрометации данных.

Большинство кандидатов, которых я собеседую, проваливаются не потому, что некомпетентны. Они проваливаются, потому что готовились по спискам: OWASP Top 10, CWE Top 25, «50 вопросов для собеседования AppSec». Списки дают словарь, но не дают грамматику. Когда интервьюер спрашивает «расскажите про SSRF», он не ждёт определения — он ждёт историю: что вы сделали, что увидели, что это означает для компании.

Я провёл десятки таких разговоров, и паттерн всегда один: кандидат, который хотя бы раз руками прошёл цепочку SSRF → metadata → credentials в лабораторной среде, отвечает принципиально иначе, чем тот, кто прочитал десять статей. Прочитать можно за вечер. Сделать — тоже за вечер. Но второе меняет ответ необратимо.

Рынок жёсткий: компании ищут людей, которые понимают эту цепочку на уровне рук, а не пересказывают стандарты. Если базу хочется пройти системно, а не собирать по статьям — на IB Basics фундамент ИБ закрывается за пару месяцев, включая практику на реальных задачах.