1. Webhook 基础概念

Webhook 是安全运营中事件驱动架构的核心组件，也是误报复核流程的起点。理解 Webhook 的本质、运行机制以及与 API 的差异，是后续策略调优与误报分析的前提。

1.1 什么是 Webhook

Webhook 是一种反向 API，它允许系统在事件发生时主动向指定 URL 发送 HTTP 请求（通常是 POST），将事件数据实时推送给接收方。在安全场景中，Webhook 常用于将告警、威胁情报、策略变更等事件即时送达 SIEM、SOAR 或工单系统。

1.2 Webhook 的工作原理

Webhook 的工作流程包含三个角色：事件源（如 WAF、IDS）、Webhook 提供方（配置回调 URL 的系统）和接收方（如 SOAR 平台）。其典型交互步骤如下：

1. 注册回调：接收方在事件源系统中注册一个唯一的 HTTPS URL 作为 Webhook 端点。
2. 事件发生：事件源检测到安全事件（如 SQL 注入攻击、异常登录）。
3. 构建载荷：事件源将事件数据序列化为 JSON/XML 格式，包含时间戳、事件类型、源 IP、告警等级等字段。
4. 发送请求：事件源向注册的 URL 发起 HTTP POST 请求，载荷放在请求体中。
5. 接收与处理：接收方解析请求，验证签名，执行自动化动作（如创建工单、触发剧本）。
6. 响应确认：接收方返回 HTTP 2xx 状态码确认接收；若返回非 2xx 或超时，事件源按重试策略重新推送。

1.3 Webhook 与 API 的区别

Webhook 和 API 虽然都基于 HTTP 协议，但在通信模式、触发方式和适用场景上有本质区别。下表从安全运营视角进行对比：

1.4 Webhook 的常见安全风险

在误报复核场景中，Webhook 本身也可能成为误报的来源。以下是需要关注的几类风险：

• 重放攻击：攻击者截获 Webhook 请求后重复发送，导致重复告警。解决方案：在载荷中加入唯一 ID 和时间戳，接收方做幂等性校验。
• 签名伪造：若签名算法薄弱或密钥泄露，攻击者可伪造合法 Webhook 请求。解决方案：使用 HMAC-SHA256 签名，并定期轮换密钥。
• 载荷篡改：中间人攻击修改请求体内容。解决方案：强制使用 HTTPS，并对载荷整体签名。
• 重试风暴：接收方短暂不可用时，事件源大量重试导致接收方过载。解决方案：配置合理的重试次数和退避策略，设置速率限制。

1.5 一个典型的 Webhook 载荷示例

以下是一个安全告警 Webhook 的 JSON 载荷示例，误报复核中需要重点关注 alert_type、severity 和 source_ip 字段：

{
  "webhook_id": "wh_20250321_001",
  "timestamp": "2025-03-21T14:30:00Z",
  "source_system": "WAF-Prod-01",
  "event": {
    "alert_type": "SQL_INJECTION",
    "severity": "high",
    "rule_id": "OWASP-942100",
    "source_ip": "203.0.113.45",
    "target_url": "https://example.com/login?user=admin' OR '1'='1",
    "user_agent": "Mozilla/5.0 (compatible; MaliciousBot/1.0)",
    "action_taken": "blocked"
  },
  "signature": "a1b2c3d4e5f6..."
}