文章总结： 本文深入剖析HTTPHop-by-Hop头滥用技术，揭示攻击者利用Connection头声明自定义逐跳头，诱导代理剥离Cookie、Authorization等关键头，实现绕过认证、隐藏源IP、绕过WAF、CPDoS及SSRF等攻击。文章详述攻击原理、六类实战场景及防御要点，建议代理层严格按RFC解析Connection头，强制应用层鉴权，并配置可信的X-Forwarded-For链。 综合评分： 88 文章分类： WEB安全,红队,渗透测试,漏洞分析,安全建设
Hop-by-Hop头滥用：HTTP代理链上的隐蔽攻击面
原创
Red Hunter Red Hunter
黑白之道
2026年10月4日 09:39 韩国
在小说阅读器读本章
去阅读
在公众号小说中沉浸阅读
导语：HTTP/1.1规范里规定，Connection头可以声明一组”只对单跳连接有效”的自定义头，下游代理会把它们从请求里剥掉。听起来像规范细节，攻击者却把它玩成了绕过认证、隐藏源IP、打穿WAF的万能钥匙。
一、什么是 Hop-by-Hop 头
RFC 9110（HTTP Semantics）把 HTTP 头分成两类：
- End-to-End 头（端到端）：从客户端一路传到后端，中间所有代理都必须原样转发，比如
Cookie、Authorization、X-Forwarded-For - Hop-by-Hop 头（逐跳）：只在单次传输连接内有效，不能被缓存或代理转发
HTTP/1.1 规范明确规定的 H-b-H 头只有 8 个：
Connection、Keep-Alive、Proxy-Authenticate、Proxy-Authorization、
TE、Trailers、Transfer-Encoding、Upgrade
其余全是 HTTP 头。但 Connection 头有个特殊能力——声明自定义 H-b-H 头：
Connection: close, X-Foo, X-Bar
按规范，下游代理看到 Connection 头里列出的字段名，就该把同名头从请求里剥离再转发。
二、攻击原理：规范与实现的裂缝
RFC 写得很清楚：兼容代理必须把 Connection 头里列出的字段从转发请求里剥掉。但现实里很多代理实现是糊的：
- 反向代理 Nginx 在某些版本下会原样转发 Connection 头
- HAProxy 默认透传整个 Connection 头
- 部分 CDN（Cloudflare、Akamai）行为也未必一致
这就让”逐跳代理”理解出现了裂缝：上游代理往 Connection 里塞个 Cookie，下游代理没按规范剥离，原封不动转给后端——但有些场景下，下游代理又真的会剥离。
攻击者要做的就是：赌一把规范实现，把本该端到端的关键头塞进 Connection，看中间哪一跳会把它吃掉。
三、攻击链条拆解
假设架构：用户 → CDN → WAF → Nginx 反代 → 后端应用
- 应用要求必须有
Cookie才能访问 - 攻击者在请求里写
Connection: close, Cookie - CDN 把 Connection 透传给 WAF
- WAF 看到 Connection 里列了
Cookie，按 H-b-H 规则剥离这个头 - 请求到达 Nginx 时已经没有 Cookie
- Nginx 把”无 Cookie 的请求”转发给应用
- 应用如果没强制校验，直接放行 → 未授权访问
实际场景下不同位置剥头，攻击效果不一样：
- CDN 剥头：客户端真实 IP 在请求链上消失，源站看到的
X-Forwarded-For缺失，便于指纹探测 + 源站暴露 - WAF 剥头：WAF 自己”看不见”Cookie，规则匹配失效，相当于绕过 WAF
- 反代剥头：Nginx 上配置的限流、IP 黑名单全部失效，便于绕过认证
四、六类实战用途
4.1 指纹识别
往 Connection 里塞随机头名，看哪一跳报错、从错误信息里推断代理类型和版本。Nginx 和 HAProxy 对未知 H-b-H 头的处理方式不一样。
4.2 访问认证端点 / 保护资源
最直接的攻击——把 Cookie、Authorization、X-Auth-Token 塞进 Connection：
GET /admin/dashboard HTTP/1.1
Host: target.com
Cookie: session=abc123
Connection: close, Cookie
如果中间代理”听话”剥掉 Cookie，后端拿不到会话标识，攻击者就能用任何人都能访问的请求触发只有登录后才有的逻辑漏洞（比如找回密码接口返回他人邮箱）。
4.3 隐藏源 IP
CDN 后面的真实 IP 一般通过 X-Forwarded-For 头传给源站。攻击者把 X-Forwarded-For 塞进 Connection，让 CDN 在转发给源站前剥掉它——源站日志里就只剩 CDN 的出口 IP，溯源难度上升一档。
4.4 CPDoS（Cache Poisoned Denial of Service，缓存投毒拒绝服务）
通过 Connection 头让 CDN 缓存错误的响应（HTTP 400 / 405），让后续所有合法用户都拿到错误页。这是一种”低成本 DoS”，把 H-b-H 滥用玩到了 DoS 层面。
4.5 SSRF（Server-Side Request Forgery，服务端请求伪造）
部分云环境（AWS metadata、Aliyun metadata）的访问控制依赖 X-Forwarded-For 判断”内网调用”。把 X-Forwarded-For 塞进 Connection 让代理剥掉，后端以为请求来自内网 → metadata 服务被未授权访问。
4.6 WAF 绕过
WAF 一般检查 Cookie、User-Agent、Referer 这些常见攻击载荷出现的位置。把这些头塞进 Connection，WAF 在自己的逻辑层”看不到”这些字段，规则全部失效。这是 2020 年 PortSwigger 报告里专门提到的一类 WAF 盲点。
五、工具和实战 PoC
官方推荐的两个工具仓库：
- mrtc0/abusing-hop-by-hop-header — 一键 Fuzz 整套 HTTP 头
- ndavison gist — Burp 插件 + Burp 请求模板
实战 Fuzz 脚本（一行就跑遍所有头）：
for HEADER in $(cat headers.txt); do
python http://poison-test.py -u "https://target.com" -x "$HEADER"
sleep 1
done
字典来源：SecLists 的 lowercase-headers（BurpSuite-ParamMiner/lowercase-headers）。
进一步阅读：
- 0xn3va GitBook Cheat Sheet
- Nathan Davison 原文
六、防御要点
- 代理层规范化处理：Connection 头必须严格按 RFC 解析，列出 H-b-H 后必须真正剥离
- 不要把鉴权头当成 H-b-H 转发：Cookie / Authorization / X-Auth-* 必须保留到源站
- 强制应用层鉴权：哪怕 Cookie 被剥掉，后端也要校验 IP 白名单、CSRF Token、设备指纹
- WAF 配置 X-Forwarded-For 信任链：明确告诉 WAF 哪一跳是可信的，避免被前端靠 Connection 头骗过
逐跳头本来是 HTTP 协议留给代理栈的”性能优化”机制。攻击者用一句话（Connection 头里多塞个名字），就能让整个链路翻车。
原文出处：learn365 Day-10 Abusing Hop-by-Hop Headers 参考：Nathan Davison《Abusing HTTP Hop-by-Hop Request Headers》
👇 点击阅读原文，访问我的网站
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：黑白之道 Red Hunter Red Hunter《Hop-by-Hop头滥用：HTTP代理链上的隐蔽攻击面》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论