授权测试 Webhook 回调地址：用受控接收端验证服务端请求伪造风险

本次测试的目标不是证明 Webhook 能发送请求，而是在明确授权的测试环境中，判断服务端是否会请求回调地址策略不允许的目标。测试前应取得回调配置权限、触发方式、允许测试的域名和时间窗口，并准备两个自有 HTTPS 接收端。两者都必须在授权范围内；即使要验证“被策略拒绝”的情形，也不要使用内网地址、云元数据服务或第三方主机。发现非预期请求时立即停止触发，保存必要证据并清理配置。

先梳理配置与触发流程

与负责 Webhook 的团队确认：谁可以登记或修改回调地址，地址是在保存时、发送前，还是两个阶段都进行校验；哪些事件会触发投递；服务端是否自动跟随重定向，以及是否有重试。记录预期策略，例如“只允许已登记的接收域名”，不要把测试人员的猜测当成产品要求。

准备两个用途明确的端点：

• 端点 A：策略允许的自有地址，用于基线投递，并可按预先约定返回固定的重定向响应。
• 端点 B：同样由测试方控制、但不在被测策略允许范围内的地址，仅用于观察服务端是否跟随跳转。

两个端点都应只接收测试事件，使用不含业务敏感信息的唯一标识关联记录。控制触发次数；若投递可能重试，提前约定观察时长，避免把一次测试误记为多次独立请求。

提出假设并做受控验证

先将回调配置为端点 A，触发一次低影响的测试事件。确认 A 收到请求后，核对时间、事件标识、请求方法和可见来源。A 收到回调只证明投递链路可用，不证明存在服务端请求伪造风险；还需要结合服务端投递日志，排除浏览器、测试脚本或其他系统发起请求的可能。

随后在团队确认策略和授权范围后，分别检查两个边界：

1. 直接地址校验：尝试将回调地址改为端点 B。记录界面或 API 是否拒绝、配置是否实际保存，以及是否发生投递。若策略要求拒绝 B，而请求已到达 B，需核对校验发生在哪个阶段及实际生效条件。
2. 跳转目标校验：恢复使用允许的端点 A，让 A 对指定测试路径返回一个固定的 307 重定向，目标仅为端点 B；再触发一次测试事件。观察 B 是否收到请求，并核对服务端是否记录了跳转。固定目标比开放式跳转参数更容易控制测试影响。

不同 HTTP 客户端对重定向、请求方法及请求体的处理可能不同，不能仅凭 A 返回了 307 就认定服务端访问了 B。反过来，若 B 收到请求，也要结合事件标识、时间线和投递日志，确认它来自该次 Webhook 投递。不要通过更换为内网或元数据地址“补强证明”。

留存证据并判断风险

建议按同一事件标识整理配置记录、测试事件、接收端日志和服务端投递日志。接收端日志至少保留时间、路径、方法、响应状态及必要的来源信息；请求体如含敏感数据，应按约定脱敏或不留存。

报告应写明授权范围、账号角色、配置入口、事件触发条件、两端点的策略归属、重定向状态码、时间线及日志关联方式。结论要与证据相称：收到正常回调不是漏洞；确认服务端越过既定地址策略访问 B，才构成需要处置的校验失效证据。这项受控测试本身不证明服务能够访问内网等受限制网络。

整改与复测

开发侧应在保存回调地址和每次实际投递前执行一致的地址策略；若允许重定向，应对每一跳的目标重新校验，或在业务不需要时禁用自动跟随。校验还应覆盖解析结果和实际连接目标，并由网络出站控制提供独立约束，避免只依赖字符串形式的域名判断。配置变更、拒绝原因和投递结果应进入可审计日志，同时避免记录完整密钥或敏感请求体。

整改后用相同的 A、B 和测试事件复测：确认正常投递仍成功，直接配置 B 按策略被拒，A 跳转至 B 时服务端不向 B 发起请求，并核对拒绝日志。结束时删除测试回调、关闭固定跳转、停止触发任务，检查重试队列中是否还有待投递事件；如测试引起异常，按预案恢复原配置并通知业务负责人。