Bug2Lab — SSRF: сервис ходит куда скажет пользователь

SSRF: сервис ходит куда скажет пользователь

У нас есть эндпоинт-прокси: он скачивает указанный URL и отдаёт ответ клиенту. Проблема — мы не фильтруем, куда ходим. Злоумышленник может заставить сервис обращаться к внутренним адресам и вытягивать чувствительные данные.

Как выглядит атака

Атакующий вызывает:
/proxy?url=http://169.254.169.254/latest/meta-data/
Это метаданные облака (включая ключи доступа). Наш сервис, имея внутренний доступ, отдаёт их наружу.

GET /proxy?url=http://169.254.169.254/latest/meta-data/
200 OK

iam/security-credentials/app-role:
AccessKeyId=AKIA...PROD
SecretAccessKey=wJalrXUtnFEMI/K7MDENG/...PROD

Почему это стало возможным

Мы просто берём URL из параметра и ходим туда RestTemplate'ом. Никакого allowlist, никакой фильтрации внутренних адресов.

Проблемный код
@GetMapping("/proxy")
public String proxy(@RequestParam String url){
    RestTemplate rt = new RestTemplate();
    return rt.getForObject(url, String.class); // ❌ SSRF
}

Как это чинится правильно

Разрешаем только ограниченный набор доменов (allowlist). Любые локальные / внутренние / облачные метаданные — блокируем.

Исправленный паттерн
@GetMapping("/proxy")
public String proxy(@RequestParam String url){
    if (!url.startsWith("https://api.partner.example/")) {
        throw new ResponseStatusException(HttpStatus.FORBIDDEN,"URL not allowed"); // ✅
    }
    return safeRestTemplate.getForObject(url, String.class);
}

bug2regressРегрессионный тест

Тест пытается сходить через /proxy к внутреннему адресу 169.254.169.254. Если видим 200 — билд стопается. Ожидаем 403.

#!/bin/bash # ssrf-check.sh STATUS=$(curl -s -o /tmp/meta.txt -w "%{http_code}" \ "https://staging.example.internal/proxy?url=http://169.254.169.254/latest/meta-data/") if [ "$STATUS" = "200" ]; then echo "[BLOCK] SSRF: сервис даёт доступ к внутренним метаданным" exit 1 fi echo "[OK] Внутренние адреса заблокированы (HTTP $STATUS)" exit 0

Это закрывает класс атак, а не только конкретный URL.

Проверка пониманияЧто пошло не так?

Сервис ходил по любому URL, который передал пользователь.

Сервис не фильтровал обращения к внутренним адресам (169.254.169.254 и т.д.).

В коде был выключен HTTPS на фронте.

Фикс — жёсткий allowlist доменов / сервисов, к которым можно ходить.

Стандарт:прокси/превью/загрузка-URL никогда не должны ходить куда угодно. Только к заранее разрешённым хостам.

Теория (по желанию) SSRF = «сходи вот туда и принеси мне секреты из внутренней сети»

🌐1. Что такое SSRF?

Server-Side Request Forgery — мы убеждаем сервер сходить туда, куда мы хотим, а не туда, куда он должен. Сервер — доверенный внутри инфраструктуры, поэтому он может видеть адреса и сервисы, куда клиент снаружи не достучится никогда.

🗝️2. Чем это опасно?

Доступ к облачным метаданным (credentials в AWS/GCP и т.д.).
Запросы к внутренним админ-панелям, которые «только с локалки».
Обход firewall'ов и доступ в подсети, где сидят БД и очереди.

То есть атакующий может получить ключи, с которыми потом двигается уже как внутренний сервис. Это уже почти полный компромисс.

🧪3. Почему это появляется?

Мы хотели «удобный предпросмотр URL» или «универсальный прокси».
Сделали быстро: return restTemplate.getForObject(url).
Потом забыли ограничить список разрешённых адресов.

Это UX-фича, которая внезапно стала дырой уровня «полный доступ к внутренней сети».

📏4. Новый стандарт

Разрешён жёсткий набор хостов (allowlist).
Запрещены приватные адреса (10.x.x.x, 169.254.x.x и т.д.).
Любая «универсальная прокладка» URL = автоматически high risk и тревога безопасности.

🚦5. Почему нужен регресс

Даже если мы пофиксили /proxy, завтра кто-то сделает /previewImage?url=... и повторит ту же ошибку. Автотест, который пытается достучаться до внутреннего метадата-сервиса, валит билд. Это техническая гарантия, не просто «ребята, помните?»

✅6. Что говорить руководству

Да, у сервиса был доступ к внутренним секретам через пользовательский URL.
Да, теперь есть фильтр доменов и блок внутренних IP.
Да, регресс не даст этой дыре вернуться в прод молча.

bug2regressРегрессионный тест

Проверка пониманияЧто пошло не так?

Теория (по желанию) SSRF = «сходи вот туда и принеси мне секреты из внутренней сети» раскрыть

Теория (по желанию) SSRF = «сходи вот туда и принеси мне секреты из внутренней сети»