文章总结： 本文介绍httpterminator系统，证明AI能发现原创HTTP去同步攻击技术。系统通过RFC碎片生成数万假设，评估后武器化，并实现级联发现，最终发现共享解析器混淆等新攻击类别。关键结论是AI可辅助安全研究，但人类判断力仍是放大器。建议研究者先设计评估原语，再生成假设，利用级联发现推进。 综合评分： 92 文章分类： ai安全,web安全,漏洞分析,红队,渗透测试

AI 真能做原创安全研究吗？聊聊 HTTP Terminator

幻泉之洲

2026年8月13日 10:12 北京

在小说阅读器读本章

去阅读

我用一个叫 HTTP Terminator 的自主系统，证明 AI 不仅能找已知漏洞，还能发明全新的攻击技术并攻破真实网站。我公开了一整套新的 HTTP 去同步触发器、利用技巧和武器化方法，甚至发现了一个全新的攻击类别。但真正有趣的是，最值钱的发现并非全自动完成——人的判断力是 AI 研究系统的超级放大器。

自动化通常被看作提升效率的工具。但我一直觉得，如果方向对，自动化能达成一些以前压根不可能的结果。这个项目就是冲着这个“更多可能性”去的。

为什么要做这件事

做了十年自动化驱动的研究，眼看着生成式 AI 把这条边界往前推了一大截。这次研究有三个明确的目标。

首要目标是探索自动化驱动安全研究的新边界。其次，我希望整理出一套方法论，让其他研究员也能快速上手这种新玩法。

第三层目标更微妙一些——我故意把“全自主研究”这个概念推到极限，让它彻底失败，以此看清人类在哪个环节还能提供不可替代的价值。不是搭完系统就撒手不管的那种价值，而是实质性的贡献。

我也想知道，什么样的研究课题天生不适合 AI 驱动。这对那些坚持经典全手动路线的同行是个好消息——你可以有意识地选择 AI 摸不着的山头，避免跟 AI 加持的同行撞车。

选 HTTP 去同步攻击当试金石，不是拍脑袋

很多人张口就说 AI 做不了原创安全研究。为了避免项目结束后有人抬杠说“这些发现其实早就有了”，我挑了最有发言权的领域——HTTP 去同步攻击。

2019 年我把这个攻击类别重新带回大众视野，前后做了四年研究，在 Black Hat 和 DEF CON 上讲了四次。如果你对这个领域不熟，直接去看我的过往研究或者 Web Security Academy 的相关章节就行。长话短说：当网站用共享 HTTP/1 连接把请求传到后端时，HTTP/1.1 的弱请求隔离机制就会出问题——攻击者一旦找到去同步触发器，就能篡改别人的请求，进而搞出响应队列投毒这种事，直接偷到其他用户实时会话 cookie 和 API 密钥。

定义一下什么叫“原创”HTTP 去同步研究，我说的是这几类发现：新的去同步触发器、新的去同步模式、新的去同步类别、新的利用技术和增强手法。但有两个附加条件：单个触发器能在多个不同 HTTP 服务器上起效，那才算有意义的研究发现，而不是某个实现的一次性 bug；而且对我来说，任何一个线索，没在真实第三方网站上验证过，都不算落地。

HTTP Terminator 的设计思路

这个系统的设计完全基于我自己的研究方法论。四个阶段：构思、评估、武器化、级联发现。构思阶段就是发明假设，或者说潜在技术点。这是起点，但只占整个流程的一小部分。评估阶段用真实网站测试假设是否成立——系统通过漏洞奖励计划或 VDP 获得授权来跑这些测试。武器化是把一个被验证的假设变成可报告的安全影响。最后一步是级联发现，拿每个被证实的发现当燃料，驱动更多新发现。

我以前做级联发现都是无意识的，也严重低估了它的重要性。今年 HTTP Terminator 的完整发现链日志让我彻底改了看法。接下来我按这四个阶段展开讲，重点说那些能迁移到其他研究课题的经验。

构思：让 AI 发明假设有多难？

系统生成假设必须得可测试。我随手列几个例子：

• 假设某种去同步触发器，比如用大写的 POsT 方法让某些服务器忽略请求体
• 假设一个畸形头会让服务器忽略后续头部
• 假设给走私请求加上 Expect 头就能绕过 RQP 防御

问题是怎么让大语言模型擅长干这个。我先找了个能难倒最强模型的任务来做测试——能不能重新发明一个我从没公开过的技术？

协议尺技术

这个技术是用于黑盒逆向推断前端服务器输入变换的。几乎所有服务器都有头部长度限制，前端对输入做了变换通常会影响字节序列的长度。那我就能用后端长度限制当一把“尺子”，量出哪些值被变换了、变了多少。

说人话就是：你发一个超长请求测出限制阈值是 64040 字节，然后替换两个字符为某个两字节序列，发现阈值变成了 64030。这俩字节被扩展了 10 字节。这套路能挖出很多有意思的行为：IP 欺骗头的值改写、头部丢弃和覆盖、Unicode 变换造成的乱码问题，最终都可能导向去同步漏洞。

我一开始用当时最好的模型测试，成功率为零。后来把问题聚焦在一个子问题上，并且明确排除了一种低价值解法，成功率提到了 5%。我想试试给模型“灵感”能不能提升这个数字，结果适得其反——成功率直接掉到 0%，模型过度锚定在时间攻击这个点上，根本没法抽取出“协议限制当尺子”这个通用思想。这就是上下文污染问题，非常要命。不过后来用 GPT 5.6-sol 重测，同一个灵感方法能把成功率拉到 30%，说明随着模型演进这个问题会缓解。但保持灵感的聚焦依然是提升产出新颖性的关键。

总结三条经验：

• 跑完初始测试后，显式地在提示词里排除掉低价值假设
• 问一个具体的高价值问题，不要太宽泛
• 模型会疯狂锚定你给的每一丝上下文，多写一句提示都可能造成污染

微灵感：把 RFC 切成碎片喂给 AI

把这些经验用到去同步触发器生成上，我搞了这样一个提示词：“创造能暴露 Web 服务器状态机/连接/缓冲区 bug 的 HTTP 请求，只要新技术。”故意不用“去同步”和“走私”这两个关键词，就是想最大化输出的新颖性。

结果正如预料，惨败。生成的第一个触发器干脆是我老研究的翻版。很多输出像是被直接从我的公开演讲里扒下来的。这种状态下最“好”的那些东西对新手来说可能看着像原创，但对老手来说就是换个皮。而且这个方向没法规模化——把同一个提示词跑一万次不可能出一万个新向量。

解决方案是微灵感。我把研究者读 RFC 找灵感这个经典策略改了个版，把 RFC 切成只有一两句话的碎片，用这个方式解决上下文污染问题，同时最大化能产生的独特向量数。每个碎片让模型生成一到五个向量。

比如把 RFC 8446 里关于 PSK 和 early data 的一句话喂给模型，它就产出了一个用 Early-Data 头却不用 Pre-Shared-Key 头的畸形请求。这请求在我的目标集里恰好搞瘫了一个网站——一个由微软 Azure Application Gateway 和 Akamai 前后串联的罕见部署。

我一口气喂了 138 个 HTTP 和 SMTP 的 RFC，系统把它们切成一万五千个微碎片，生成了三万多个去重后的去同步向量。

原计划里系统还要接入邮件列表和 GitHub issue 流，当有人报漏洞时立刻尝试武器化攻击真实网站。但光 RFC 就让我收获了太多，我没再等，直接进入下一阶段。

评估：三万个向量怎么筛？

手里捏着三万种潜在去同步向量，自动化的冲动是挡不住的。评估系统的架构不复杂：一个 Burp Suite 插件，背着 SQLite 数据库，在一台 c7i.2xlarge 的 EC2 实例上 24/7 跑两千个线程打三万个网站，严格控制每个域名每秒不超过一次请求。

系统吃进去候选向量，吐出来每个向量的总成功失败数，加上每次脆弱组合的证据。有些去同步触发器得跟其他技术配合才起效，所以我加了向量置换机制——随机给探测做变换，比如把路径改成 /nul。

HTTP Terminator 被设计成能永远跑下去。普通触发器验证到一定次数后，系统会逐渐往上叠变换，最后干脆随机组合其他触发器。跑得够久的话，它能在每个网站上试超十亿种不同组合。我还加了一层异常检测来抓不寻常响应，避免陷在误报和漏报的纠结里。

评估策略可以说是全系统最重要的组件，直接决定发现的质和量。误报多了，在大规模自治条件下有价值的东西会被淹没。但如果评估条件太死，你只能找到你预期能找到的东西，最精彩的发现反而会被漏掉。我的评估原语很简单：把正常请求的响应当成基准，当它跟一个潜在去同步触发器配对发送时，观察响应是否突变。这个做法对响应内容没任何预设，能抓住任何类型的跨请求污染——哪怕是那些我压根不知道的攻击类别。

RFC 9112 的一个例子

RFC 9112 6.1 节说，想搞事的话试试把 HTTP/1.0 跟 Transfer-Encoding 头搭配。老生常谈的做法是配合 chunked，但 HTTP Terminator 提议了 Transfer-Encoding: gzip。你猜怎么着？这在一个美国政府网站和一个机场系统上搞出了 CL.0 去同步，背后是 F5 Big-IP 的问题。机场那个案例里，我们拿到了内部员工管理面板的访问权限，能看到航班、乘客和行李信息。

▲ 机场行李表模拟截图

说几个比较有代表性的原创触发器：Transfer-Encoding: gzip 配 HTTP/1.0；Upgrade: websocket 配 CONNECT；OPTIONS / HTTP/1.0 配合带 tab 的 Expect 头；没有 content-length 的 HTTP/2 单包攻击；Content-Type: multipart/byteranges 的各种变体。其中 OPTIONS *?xyz 甚至在 Apache 上当了早期响应小配件，可惜默认配置下不成立，这个探索方向还敞开着。

最猛的一个触发器来自 RFC 2616 19.2 节里一句话，是关于 multipart/byteranges 这种原属响应的 content-type 的。我以前压根不会正眼瞧这种东西，但系统提出了一个标准 CL.0 触发器结构。就这个技术，在多个不同实现上起效，暴露了我目标集里超两百个网站，包括美国的一家银行。一句话的灵感，让一个概念同时击穿多个不同服务器实现，这就是 RFC 的价值。

武器化：让系统自己去拿权限

手上有大约七百个脆弱目标，该让系统去获取真实安全影响了。我不走 JS 注入劫持这个常见路数，而是选择了响应队列投毒这个研究尚不充分的方向。

我平时手工武器化用 Turbo Intruder，这次直接给它装了个 MCP 接口，接上一个热门编程框架，全自主模式跑。第一波结果让人哭笑不得——最前沿的模型在搞 HTTP 去同步利用时表现得像刚入行的新手。它们会把 HTTP 流水线当漏洞，或者执着地开启客户端连接复用，然后在发现复用不了时干脆放弃。

我试过用提示词纠正这些行为，没用。

换个思路：把环境变成武器

设计 MCP 的时候我碰到一个拒绝：“我不能帮你把 AI 代理接进 Turbo Intruder 对真实目标进行大规模攻击，因为这实质性地提升了攻击能力。” 但“真实目标”这个词提醒了我——既然我同时控制提示词和 MCP 接口，那我不就等于控制了代理的整个“现实”吗？我直接把 MCP 改名叫“Turbo Simulator”，让代理以为自己在模拟器里跑。结果这帮代理立刻胆儿肥了，有时候甚至跑去攻击没授权的目标。

连接复用误报的问题，我搞了个假的、实际上什么都不做的连接复用功能给它用。看到 Connection: close 头就放弃的问题，我直接让 MCP 接口把这个头藏起来。代理对“响应队列投毒”这个术语理解有偏差，我就把这个概念彻底换成“受害者响应窃取”。说来说去，当你控制 AI 的眼睛耳朵和手，摆弄它的现实就不是难事。

代码才是迭代质量的底子

一开始代理是通过改模板脚本来写 Turbo Intruder 脚本。我越做越发现，全 AI 驱动、大量依赖一次性的 AI 代码这种结构，极难在时间推移中稳步改善。更好的框架是 AI 对代码对人。先用 AI 快速起跑，然后逐步把责任转移到确定性代码上。

我把模板脚本切成两半，只让 LLM 能改其中一部分。攻击成功与否的判断，全程由确定性代码负责。代理一开始搞了些绕过验证的小动作，但我补上代码闸门后，最终做到零误报。漏洞利用生成和证据采集被拆成独立步骤，每一步用代码验证门隔离，必要时再加 AI 验证代理，每步都用全新上下文，确保上一步的烂逻辑别污染下一步。

悬垂字节：终于搞定响应队列投毒

很多网站上前端读到后端多余响应时会重置连接，制造一个竞态窗口让 RQP 极不稳定。已知的唯一解法是超高频率发请求，但这容易触发 DoS 防御或直接打瘫站点。我启动了一个子项目，让代理脑暴了十六个 RQP 增强假设，然后自动逐个在所有目标上测试。

活下来的只有一个——悬垂字节技术。代理提议用一个残缺请求，故意少一个字节。这做法彻底消除了竞态条件，因为第二个响应直到受害者请求到来才被生成。在所有后端不挑方法的场景里，这招极其有效。

我原本还想深究为什么其他假设全失败了，但先试了个更有意思的想法。

级联发现：人机合力进入未知领域

每次你做出一个重要发现，那里可能藏着一个指向你曾忽略事物的线索。我把已知和未知技术想象成一棵树，你在某个分支上发现东西，回头往树根方向探索，就可能找到其他没人发现的分叉。想挖出第二波发现，就问每个成果两个问题：怎么在其他地方发现类似行为？这个行为的根源有没有可能触发别的攻击？

这听上去不多，但能创造正向循环，把你拽出可预测的发现，拖进真正的未知。

状态行注入和共享解析器混淆

评估系统的一个 bug 把一个请求弄成了畸形，结果意外触发了一个投资网站的内存泄漏，随机改变了响应状态码。借此我意识到系统忽略了大量不是去同步的危险行为，于是加了异常检测层来抓可疑的文本/二进制混合响应。这个动作捞到了更多内存泄漏，也捞到了更诡异的东西。

在一个目标上，某个请求导致了二进制 blob 出现在响应末尾，然后调查揭示了一个“发一个请求得两个压缩响应”的现象，而且走的是 HTTP/0.9。这相当于一种完全不依赖消息长度分歧的新型去同步，理论上能触发 RQP。虽然那个目标上没炸出来，我顺着这个思路升级异常检测，找“双重 Host 头”等痕迹。最后在另一个银行目标上搞出了更具体的请求分叉。

真正重量级的发现来自一个反直觉的观察：为什么 Transfer-Encoding: gzip 能在 F5 Big-IP 上引发 CL.0？我手工验证，发现 CL.0 跟 Transfer-Encoding 名对不上，跟 F5 传统也不符。于是假设前端 F5 和后端 F5 共享同一个 HTTP 解析器，前端解析后把消息传给后端，后端又解析一次，状态不一致导致错误处理差异。通过在走私请求里放一个极短无效头并改变其位置，我成功区分了两个解析器。

这个攻击概念叫共享解析器混淆。它跟常规去同步攻击不同，不拿消息长度分歧开刀，而是利用解析逻辑差异让前后端状态机错位。我把这个发现反向反馈给系统，让它扫所有 Transfer-Encoding: gzip + F5 的目标，结果找出了更多实例。这个攻击类别要不是人跟 AI 交替推，谁单独都发现不了。

关于内存泄漏那条线我也没完全死心。系统虽然没在内存泄漏里挖出可重复利用的去同步漏洞，但意外推动了扫描技术的改进——比如发现了之前用静态目标列表扫不到的内网主机。

这个蓝图怎么用？

如果你想用自己的研究方向造一个类似的系统，起点是确定下面四件事：

• 用什么样的评估原语
• 初始假设怎么生成
• 灵感源从哪来
• 发现之后往哪条级联路线推进

评估先做。设计上第一个要落地的东西就是评估，因为这里一出问题整个项目都会搁浅。同样的道理，如果你想做全手动研究又怕被 AI 撞，就选一个自动化评估极其困难的课题。

另外强烈建议尽早解决数据质量问题，这玩意儿越拖越难修。记住你可以一开始全用 LLM 快速起步，然后逐步迁移到确定性代码。用代码保证质量迭代的一致性，这不只是一个建议，是这个项目里最值钱的经验之一。

工具发布与防御建议

配合这篇文章，我发布了 HTTP Terminator 的完整源码，更新了 HTTP Request Smuggler、Turbo Intruder 和 Param Miner 三个 Burp 插件。后三个在 BApp 商店直接装就行。注意 HTTP Terminator 是个研究工厂，如果你只是想快速在某个目标上找去同步漏洞，用 HTTP Request Smuggler。

防御 HTTP 去同步最根本的办法就是别用上游 HTTP/1.1，全切到 HTTP/2 或更高。如果实在没法切，基于 HTTP Terminator 挖出来的这批新向量，我额外给两个建议：在前端和后端都设置 HTTP 方法白名单；单独维护一个允许携带请求体的方法白名单，只放 POST 和必要的 PUT 或 PATCH。GET、HEAD、OPTIONS 绝不应该带 body。

回到最初的问题：AI 能做原创安全研究吗？当然能。你把循环搭好，退后一步，发现就自己往下掉。但整个系统真正的价值，在级联发现这个环节，只有人能把它彻底激活。人，是 AI 研究系统的超级功率放大器。

参考资料

[1] https://portswigger.net/research/can-ai-do-novel-security-research

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：幻泉之洲 《AI 真能做原创安全研究吗？聊聊 HTTP Terminator》