AI 报出的 SSRF 为何复测失败

AI 渗透测试第一次报出 SSRF，第二次却没有发现，漏洞就算修好了？作者的答案是：先别关闭问题。两次扫描之间，变化的可能是请求实际经过的网络路径，而不是应用的安全边界。

这篇短文值得读的地方，是把「模型判断准不准」转成一个更容易核查的问题：请求最终连到了哪里？对于维护 URL 抓取、资源代理等服务的前端和全栈开发者，这也是排查偶发漏洞、验证修复是否有效的实用思路。

URL 检查通过，连接仍可能越界

SSRF（服务端请求伪造）指攻击者利用服务端发起请求，访问原本不应触达的目标。原文从一个扫描场景切入：接口接收 URL、抓取资源并返回响应，代理第一次通过重定向访问了内部服务，第二次测试却没有复现。

作者没有提供完整请求或抓包记录，因此这还不能当成一份经过验证的实验报告。他接着提出了两条需要检查的路径。

第一条是 DNS 重绑定（DNS rebinding）。假设应用检查域名时，DNS 返回公网 IP，于是校验通过；到了真正建立连接时，如果再次解析得到私网 IP，请求就可能进入内部网络。

问题在于，检查时认可的地址，未必就是连接时使用的地址。

但作者也明确限定：第二次 DNS 解析并不一定发生。 HTTP 客户端、DNS 缓存、连接复用以及代理都会影响实际行为，不能看到结果不稳定，就断言发生了 DNS 重绑定。

第二条是重定向。最初的 URL 指向公网主机，却返回了跳往另一个域名的响应。如果应用只检查入口 URL，后续请求就可能绕过限制。

原文援引 OWASP 的 SSRF 防护建议：关闭 HTTP 客户端的自动重定向；如果业务必须支持重定向，就在发起下一跳请求之前，检查每个目标。

这两条路径有共同要求：负责实际连接的组件必须执行目标限制。入口处检查一次域名，不足以保证整个请求过程安全。作者还建议核查出站网络规则，确认它们是否阻止访问内部地址范围。

第二次没扫出来，究竟证明了什么

即使代理两次发送完全相同的请求，也不能假定它们走了相同的网络路径。

DNS 可能返回不同地址，重定向目标可能变化，HTTP 客户端也可能一次复用已有连接，另一次新建连接。只看模型最后生成的报告，无法判断究竟发生了哪一种情况。

因此，作者建议每次运行都保存以下证据：

• 原始请求，用来核对代理实际提交了什么。
• DNS 解析结果和重定向历史，用来还原目标如何变化。
• 建立连接时的目标 IP，以及响应状态。
• 目标构建标识，用来确认测试的是哪个应用版本。

这里最关键的是连接时的目标 IP。代理提交的域名只能描述它想访问哪里，不能单独证明请求最终抵达哪里。

作者还区分了「回放执行过程」和「复现漏洞」。回放保存的工具调用，可以重建代理此前做过的操作；复现漏洞则需要验证，当前应用是否仍然允许危险访问。前者不能代替后者。

第二次扫描没有发现问题，不足以证明漏洞已经消失。

关闭问题之前，需要回答：应用确实拦住了请求，还是请求这次没有到达原来的目标？

我的判断

我认同作者把排查重点放在网络证据上。对于依赖外部状态的测试，模型报告只是结论层；缺少请求、解析和连接记录，很难判断一次阴性结果的含义。

不过，这篇文章提供的是排查框架，没有给出具体 HTTP 客户端、配置、抓包证据或修复前后的对照数据。DNS 重绑定和连接复用是可能的解释，不能替原文认定为事故原因。

和「让 AI 再扫一次」相比，保留执行证据更有助于解释差异；但证据完整也不代表防护完整。逐跳校验、连接组件执行限制、出站网络规则，分别约束不同环节，不能仅凭其中一项就宣布修复成功。

对一般团队来说，先补齐能关联同一次运行的请求与网络记录，比要求模型写一份更详细的总结更有实际价值。

能拿来做什么

• 如果你维护 Node 服务中的 URL 抓取或资源代理功能，先核对 HTTP 客户端是否自动跟随重定向；业务需要跟随时，检查每一跳的目标校验是否真正执行。
• 给 AI 安全扫描保留原始请求、DNS 结果、重定向历史、连接目标 IP、响应状态和目标构建标识，让两次结果可以逐项比较。
• 验证 SSRF 修复时，确认危险目标确实被应用或出站规则阻止。遇到第二次扫描未发现问题，先解释请求路径的差异，再决定是否关闭漏洞。