Bypass SSRF: Обход фильтров хоста

# SSRF: обход чёрного списка хостов ## Сценарий Вы аудируете **SecureHooks** — платформу интеграций, где пользователи настраивают webhook-уведомления: указывают URL внешнего сервиса, а сервер отправляет туда тестовый запрос. После прошлого инцидента команда добавила «защиту»: имя хоста из URL сверяется со списком запрещённых строк, при совпадении запрос блокируется. Команда уверена, что внутренняя сеть теперь недоступна. По данным аудита, в приложении остался служебный эндпоинт, доверяющий обращениям с loopback-интерфейса, — до него и нужно добраться, имея обычную учётную запись. ## Цель 1. Изучите фактический список запрещённых строк и то, как именно сверяется имя хоста. 2. Найдите запись адреса, которая строковой проверкой не блокируется, но сетевым стеком интерпретируется как внутренний адрес этого же сервера. 3. Через серверный клиент обратитесь к служебному эндпоинту и извлеките флаг. ## Теория Чёрный список по строковому представлению хоста — самая частая ошибка при «латании» SSRF: разработчик блокирует несколько точных имён, а сетевой стек понимает адреса куда либеральнее. Один и тот же внутренний адрес записывается десятками способов: сокращённые формы IPv4, запись числа в разных системах счисления, IPv6-нотации, специальные домены, резолвящиеся в тот же адрес, «неопределённый» адрес. Ни одна из этих записей не совпадает со строками списка, но все приводят соединение туда же. **Уязвимый паттерн:** ```go blocked := []string{"localhost", "127.0.0.1", "internal", "0.0.0.0"} if strings.Contains(strings.ToLower(parsedURL.Hostname()), b) { /* блокировка */ } resp, err := client.Get(webhookURL) ``` Фильтр проверяет текст, а подключение происходит по адресу — разрыв между синтаксисом и сетевым смыслом и есть уязвимость. ## Точка входа атаки `POST /webhook` — форма тестового webhook-запроса, поле `webhook_url` (требуется вход). * **Обычный пользователь:** `demo` / `demo` * **Цель:** служебный эндпоинт приложения, доступный только с loopback-источника; его ответ содержит флаг