把相对地址补成绝对地址的函数，怎么会变成拒绝服务的入口

把相对地址转换成绝对地址的公共函数，为什么会成为拒绝服务问题的来源？因为它做的是一件「成本由输入决定」的小事：解析、拼接、回退，每一步的耗时都跟着传进来的字符串变化。同行系统 WordPress 在 2026 年 10 月发布的安全维护版本里就写了这一条：WP_Http::make_absolute_url() 方法存在拒绝服务问题，由 Anthropic 报告。公告给出的是方法名、问题类型与报告方，利用细节没有公开，能落地的结论只有一句——被反复调用的解析代码，输入不设边界就会变成耗时入口。

一个转换函数怎么会拖垮请求

这类函数通常被很多条链路共用：正文里的相对路径要补全、跳转目标要校验、远程图片地址要归一、接口参数要落地成完整地址。共用意味着调用量大，也意味着单点成本会被成倍放大。

让它变慢的输入往往有三种形态：长度远超正常范围的地址；反复出现同级片段、需要多次回溯的路径；以及看似合法但会让解析走到回退分支的写法。函数本身逻辑没有错，错的是「输入规模不可控」这一前提。

判断是否属于这一类风险，可以只看两件事：这个函数是否处理外部可控的值；处理一个坏输入的成本是否明显高于处理一个好输入。两条同时成立，就值得加限制。

采集与远程抓图链路里谁在调用它

站内的内容采集能力（从其他网站取回内容入库）和远程抓图是两条最典型的调用方。它们的共同点是：地址由外部提供，取回动作由请求触发，处理结果还要进正文。

这就形成了一条完整的成本链——一个坏地址被传进来，解析先花一次时间，随后可能真的发出请求再花一次网络时间，最后还要把回来的内容做过滤。三层叠加时，单个请求的开销就已经不是「解析字符串」的量级。

自有系统里，内容采集与内置防护是分层存在的：AnQiCMS 支持从其他网站采集内容，同时内置 SQL 注入与 XSS 防护、敏感词过滤与防采集干扰码。采集环节解决「内容怎么进来」，防护环节解决「进来的内容怎么处理」，两层的输入校验不能互相替代。

限输入而不是限报错：三条可落地的收口

第一条是长度与前缀白名单。地址在进入解析之前先过一遍长度上限和协议白名单，明显不合规的直接拒绝，不进函数。校验的成本固定，解析的成本不固定，顺序不能反。

第二条是来源限制。允许被采集与被抓图的域名范围要显式配置，而不是接受任意地址。这一条同时挡住两类问题：耗时被外部控制，以及内网地址被当作外部地址提交。

第三条是次数与并发。采集与抓图属于「一次触发可能带多次外呼」的动作，要按请求做频次限制，并按任务设置总时长。没有时长上限时，一个慢任务可以把排队位置全部占住。

这三条都作用在进入解析之前或调用外部之前，属于「限输入」；只加异常捕获、只在报错后返回提示，属于「限报错」，对耗时没有帮助。

和注入类问题有什么不同

注入类问题的核心是「输入被当成代码执行」，地址解析类问题的核心是「输入把执行成本抬高了」。前者影响机密性与完整性，后者主要影响可用性；前者靠参数化与转义收口，后者靠限额与白名单收口。

两者的排查动作可以共用一份清单，但优先级不同：注入类问题一般要紧急跟进，因为它可能已经被利用；解析类问题在补丁到位前先加限制就能压住风险，不必把站点停掉。

写站内自查时，把「外部可控」当作同一条筛选标准更省事——只要值来自请求、正文或采集回来的内容，就同时属于两条链路的输入。

常见问题

只有公告提到某个函数名，能推断站内也有同样问题吗？ 不能。函数名是对方实现细节，站内只能按同类模式自查：有没有一个被共用的地址解析函数、它的输入是否外部可控、有没有长度与来源限制。三条成立才需要处理。

加超时不就够了吗？ 超时压住的是最坏情况，压不住中等规模的坏输入累积出来的开销。高并发下每个请求都花较多时间，即使没触发超时也会拖垮吞吐。超时是兜底，限输入是第一道。

校验放网关还是放程序？ 长度、协议、来源这三类可以放在入口层先粗筛；是否指向内网、是否属于允许的采集范围这类需要业务判断的，只能在程序里做。两层都做，顺序上入口层更早。

采集功能还要不要开？ 要按用途决定。开就配白名单与频次，不用就关掉入口。功能是资产也是入口，入口面收窄本身就是一种降风险手段。