Webhook Security: когда интеграции становятся точкой входа — 25 июня 2026 г. в 13:44:05.936
Webhook Security: когда интеграции становятся точкой входа 👋 Приветствую в мире цифровой безопасности! Разберём несколько проблем в работе с вебхуками и интеграциями. ⏺Webhook Replay - повторная отправка легитимного события: Многие сервисы принимают вебхуки без строгой проверки уникальности события. Если запрос валидный и подписан, его часто считают доверенным. POST /webhook/payment HTTP/1.1 X-Signature: sha256=abc123 X-Event-ID: 784512 {"status":"paid","order_id":1001} Проблема начинается, когда система не проверяет X-Event-ID или timestamp. Тогда один и тот же запрос можно отправить повторно, и он снова будет обработан - например, начислит бонусы, активирует подписку или повторно выполнит бизнес-операцию. ⏺Webhook SSRF - когда интеграции вызывают внутреннюю сеть: Часто вебхуки позволяют указывать callback URL или retry endpoint. Если валидация слабая, сервер начинает сам ходить по внутренним адресам. http://localhost:8080/admin http://169.254.169.254/latest/meta-data/ http://internal-db.service.local В реальных системах это превращается в доступ к внутренним API, метаданным облака и сервисам, которые никогда не должны быть доступны извне. ⏺Signature confusion - ошибка в проверке подписи: Разные команды иногда по-разному реализуют проверку HMAC. Самая частая проблема - проверка «частично» или с неправильным порядком данных. expected = hmac_sha256(secret, body) if request.headers["signature"].startswith(expected): return OK Любое смещение логики - и атакующий может подделать валидный префикс или использовать повторно подписанные данные из других окружений (dev/stage/prod), если секреты пересекаются. ⏺Как видим, часто вебхуки воспринимаются, как «безопасный внутренний канал», но по факту это внешний вход без сессии, где вся безопасность держится только на подписи и проверках целостности. 🤖Бесплатный ChatGPT