Документация › Интеграции › Вебхуки и безопасность

Вебхуки и безопасность (SSRF)

[для разработчиков] Когда бот ходит на внешние URL (твои вебхуки, CRM), платформа защищается от атак типа SSRF — попыток заставить сервер дёрнуть внутренний адрес. Эта статья — что и почему блокируется.

⏱ 7 мин · 👤 для разработчика · 🟢 live

За 30 секунд:

• Любой внешний URL (кастомный вебхук, CRM) проходит проверку безопасности перед запросом.
• Блокируются внутренние/приватные адреса: 127.0.0.1, 10.x, 192.168.x, 169.254.x, приватный IPv6 и т.п.
• Защита от DNS-rebinding: адрес «пинится» — куда проверили, туда и идёт запрос.
• Разрешены только http/https, без логина-пароля в URL; для CRM/уведомлений — только HTTPS.

Что такое SSRF и почему это важно

SSRF (Server-Side Request Forgery) — атака, где злоумышленник заставляет сервер сходить на адрес, к которому у него самого нет доступа: внутренние сервисы, облачные метаданные, локальная сеть. Поскольку бот умеет ходить на внешние URL, без защиты кто-то мог бы направить его на http://127.0.0.1/... и выудить внутренние данные.

Поэтому каждый внешний URL проверяется перед запросом.

Что блокируется

Запрос не пойдёт, если адрес резолвится в приватный/служебный диапазон:

• IPv4: 127.x (loopback), 10.x, 192.168.x, 172.16–31.x (приватные), 169.254.x (link-local), 0.x, CGNAT 100.64–127.x;
• IPv6: loopback ::1, приватные fc/fd, link-local fe80:: и IPv4-mapped варианты;
• URL с встроенными логином-паролем (https://user:pass@…);
• любые протоколы кроме http/https.

Для CRM-вебхуков и URL уведомлений дополнительно требуется HTTPS («CRM webhook URL must use HTTPS»).

Защита от DNS-rebinding

Тонкая атака: домен сначала резолвится в «хороший» внешний IP (проверку прошёл), а через миг — в 127.0.0.1 (запрос уже пошёл на внутренний). Платформа закрывает эту лазейку: после проверки адрес «пинится» — запрос отправляется именно на тот IP, который проверили (fetchPinnedToIp), а не резолвится заново. Окно подмены сведено к минимуму.

Плюс размер ответа ограничен — внешний сервис не сможет «залить» гигабайты в ответ.

Что это значит для тебя

• Твой эндпоинт для кастомного вебхука должен быть публичным (не localhost, не внутренняя сеть) и желательно по HTTPS.
• Не пытайся через бота ходить на внутренние адреса — это by design заблокировано.
• Секреты к твоему API передавай через заголовки авторизации функции (они хранятся зашифрованно), а не в URL.

📌 Про подпись. Входящие вебхуки (например, от платёжных провайдеров) платформа проверяет по подписи. А вот исходящие запросы к твоему эндпоинту платформа подписью не заверяет — если тебе нужна аутентификация входящего от бота запроса, используй секретный заголовок/токен, который задаёшь в настройке функции.

💬 Простыми словами

Раз бот умеет ходить на чужие адреса в интернете, теоретически кто-то мог бы попробовать обмануть его и заставить постучаться не наружу, а «внутрь» — на служебные адреса сервера, где лежит что-то приватное. Это известный класс атак, и платформа от него защищается: перед каждым походом на внешний URL она проверяет, что это действительно публичный адрес, а не локальный/внутренний. Все 127.0.0.1, 10.x, 192.168.x и подобные — мимо.

Для тебя как разработчика вывод простой: твой эндпоинт, который дёргает бот, должен быть нормальным внешним адресом по HTTPS, а не локальным. А пароли к нему передавай через заголовки авторизации (они шифруются), не зашивай в ссылку. Всё это — чтобы и твои данные, и платформа были в безопасности.

Дальше: → Публичный API
Связано: Кастомные вебхуки · CRM
Не получилось? → напиши в саппорт