建议为 web_fetch 增加可配置的非公网 CIDR 白名单，以支持 Fake-IP 与特殊路由环境

[Yurzi]

概要

当前 @deepseek-ai/dsh-web-fetch-http 的公网地址校验为 web_fetch 提供了重要的 SSRF 防护边界。但现有策略会阻止所有非公网 DNS 解析结果，并且没有可配置的白名单。

在一些特殊网络环境中，部分非公网或特殊用途地址段会被有意用于路由。即使请求的是合法的公开域名，DNS 也可能返回这些地址。这会导致 web_fetch 在请求进入代理或路由层之前直接失败，进而无法使用。

环境

• DeepSeek Harness：0.1.2-alpha.1
• 相关包：@deepseek-ai/dsh-web-fetch-http
• 工具：web_fetch

当前行为

resolvePublicAddresses() 会检查 DNS 返回的完整地址集合。当其中任意地址不被视为公网地址时，直接抛出错误：

if (!isPublicIpAddress(entry.address)) {
  throw new WebError(
    `URL hostname "${hostname}" resolves to a non-public IP address`,
    "WEB_BLOCKED_URL",
  )
}

当前 Provider 配置只提供以下传输和资源限制项：

• maxResponseBytes
• maxBodyChars
• timeoutMs
• maxRedirects
• userAgent

目前没有用于放行 CIDR、IP 地址或主机名的配置项。

使用场景

一些代理或特殊路由网络会故意让公开域名解析到非公网或特殊用途地址。

常见例子是 Fake-IP DNS 模式。公开域名可能被解析到 198.18.0.0/15 中的地址。这个地址是本地代理使用的路由标识，并不代表最终的上游目标地址。

当前执行流程如下：

公开域名
  -> DNS 返回 Fake-IP 或特殊路由地址
  -> resolvePublicAddresses()
  -> 地址被判断为非公网
  -> 抛出 WEB_BLOCKED_URL
  -> 请求无法进入代理或路由层

类似情况也可能发生在企业网络中，例如使用指定私有网段进行服务路由。

最终结果是：即使目标域名本身是合法的公开域名，所有受影响域名的 web_fetch 调用仍然无法使用。

改进建议

希望可以为 HTTP Fetch Provider 增加范围明确、默认关闭的白名单配置，例如：

- name: '@deepseek-ai/dsh-web-fetch-http'
  config:
    allowedNonPublicCidrs:
      - 198.18.0.0/15

为了进一步缩小放行范围，也可以支持主机名与 CIDR 联合匹配：

allowedDestinations:
  - hostname: '*.example.com'
    cidrs:
      - 198.18.0.0/15

白名单默认值应为空，以保持当前默认安全行为不变。

建议保留的安全约束

为了避免削弱现有 SSRF 防护，建议：

• 要求显式配置 CIDR，不提供 allowAllPrivateNetworks 之类的全局开关。
• 默认继续阻止回环、未指定和链路本地地址。
• 继续阻止 169.254.169.254 等云平台元数据地址。
• 同时校验 IPv4、IPv6、IPv4-mapped IPv6 和 NAT64 转换后的目标地址。
• 每次 DNS 解析及重定向后都重新应用安全策略。
• 在可行的情况下，要求主机名与 CIDR 同时匹配。
• 在配置加载阶段拒绝格式错误或范围过大的白名单项。
• 在文档中明确说明：放行地址段会扩大部署环境的网络访问范围。

另一个可选方案是，将现有的 HttpFetchResolver 自定义能力通过 Provider 配置或正式的插件扩展点公开出来。

相关讨论

这是对 #3051 中 SSRF 安全问题的后续建议。

目前加入的公网地址校验有效解决了该讨论提出的 SSRF 风险。本建议并不是要求删除或默认关闭这项保护，而是希望为确实依赖特殊网络路由的部署提供一种默认拒绝、显式配置、范围有限的例外机制。