文章总结： 本文探讨了通过输入变形、主机覆盖、WAF宽容度、代码假设以及Tor隧道等手段，如何利用反向代理漏洞直接访问内网服务。文章提供了多种攻击示例，并分享了猎人的五条提醒，强调了输入验证、库依赖、WAF局限性以及Tor安全机制的重要性。 综合评分： 85 文章分类： 渗透测试,漏洞分析,网络安全,技术标准,应急响应
一个 @ 符号，就能让代理把我送进别人家的内网
原创
升斗安全XiuXiu 升斗安全XiuXiu
升斗安全
2026年9月29日 07:58 广东
在小说阅读器读本章
去阅读
在公众号小说中沉浸阅读
【文章说明】
- 目的：本文内容仅为网络安全技术研究与教育目的而创作。
- 红线：严禁将本文知识用于任何未授权的非法活动。使用者必须遵守《网络安全法》等相关法律。
- 责任：任何对本文技术的滥用所引发的后果自负，与本公众号及作者无关。
- 免责：内容仅供参考，作者不对其准确性、完整性作任何担保。
阅读即代表您同意以上条款。
摘要：上篇三万美元赏金，起点是一个畸形的 Host 头讲了怎么让隐形系统自己暴露，以及最简单的一招——假 Host 头。这一篇把”错误路由”剩下的花样走一遍：一个不听话的输入排列、一个被忘掉的主机覆盖、一个太宽容的 WAF、一个假设”路径必须/开头”的库、还有一条把自己藏进 Tor 的通路。每一处都能把你从目标的外围，直接送进别人家的内网。
📌这篇讲什么：反向代理受托把请求转发到”正确”的内部服务器，但只要输入能被歪曲，这个”正确”就由你说了算。这一篇是五种把请求带偏的思路，从最简单的输入变形，一路讲到 Java 代码里那段看起来毫无破绽的写法——它照样被打穿了。每一节都带完整的请求原文，可以直接照着复现。最后一节会顺手打开一个叫 GlobaLeaks 的举报平台，然后发现它躲在 Tor 后面。
一、当输入开始不听话 🌀
前面说过，回连是我们唯一的探照灯。但回连这种东西，你不能指望它老老实实按你写的来。
我遇到过七台服务器组成的池子。我给它们发的是这个：
GET / HTTP/1.1Host: burpcollaborator.netConnection: close
它们却去请求 outage.<我提供的域名>——而且把我给的域名塞进路径里，塞了两次：
GET /burpcollaborator.net/burpcollaborator.net HTTP/1.1Host: outage.burpcollaborator.netVia: o2-b.ycpi.tp2.yahoo.net
这种行为你没办法预测。所以唯一合理的反应，是让自己的基础设施吃得下意外——通配符 DNS、通配符 SSL、多种协议，全都得备上。
单看这个行为，似乎没什么前途：内部服务器不太可能在 /burpcollaborator.net/burpcollaborator.net 这个路径下放敏感内容。
但如果你注册 outage.yourdomain.com，让它解析到一个内网 IP，路径规范化就会帮你把请求送到内部服务器的 webroot：
GET / HTTP/1.1Host: ../?x=.vcap.meConnection: close
服务端实际发出去的是：
GET /vcap.me/../?=x=.vcap.meHost: outage.vcap.meVia: o2-b.ycpi.tp2.yahoo.net
规范化之后，URL 变成 http://outage.vcap.me/?x=whatever。
而 vcap.me 这个域名有个很方便的特性：它的所有子域都解析到 127.0.0.1。
所以这个请求，等于在请求 http://127.0.0.1/。
Yahoo 为这个付了5,000 美元。
二、主机覆盖：白名单也是会漏的 🚪
还有一种技术，是我早年用来构造毒化密码重置邮件的。它在某台美国国防部服务器上又灵了一次。
有些服务器确实会把 Host 头做成白名单——这点值得表扬。但它们忘了一件事：请求行里的 URL 也能指定主机，而且优先级比 Host 头高。
GET http://internal-website.mil/ HTTP/1.1Host: xxxxxxx.milConnection: close
拿这个有洞的前端当跳板，我逛了一批挺有意思的内部网站：一个攻击面相当可观的图书馆，还有一个在公开论坛里被人提到过的文件传输服务。
三、模糊请求：WAF 太宽容，也不是好事 🧱
有几个目标躲在 Incapsula 的云 WAF 后面。Incapsula 靠 Host 头判断该把请求转给哪台服务器，所以上面那招在这儿不好使。
但 Incapsula 对 Host 头的解析，有个地方宽容得离谱——它对你”指定的端口”极其宽容：
GET / HTTP/1.1Host: incapsula-client.net:[email protected]: close
它会正确地把这条请求路由到 incapsula-client.net。
而 incapsula-client.net 后面的某个后端，把这段输入解析成了 URL http://incapsula-client.net:[email protected]/——于是它试图用用户名 incapsula-client.net、密码 80，去和 burp-collaborator.net 做一次认证。
除了暴露新的攻击面，这还顺手告诉了我后端服务器的真实位置。于是我直接去打后端，把 Incapsula 那层保护整个绕开了。
四、打破预期：那段”看起来无懈可击”的代码 💥
路由漏洞不总是配置错误。有时候，它就是代码问题。
New Relic 那个关键漏洞，出在下面这段：
Url backendURL = ”http://public-backend/”;String uri = ctx.getRequest().getRawUri();URI proxyUri;try { proxyUri = new URIBuilder(uri) .setHost(backendURL.getHost()) .setPort(backendURL.getPort()) .setScheme(backendURL.getScheme()) .build(); } catch (URISyntaxException e) { Util.sendError(ctx, 400, INVALID_REQUEST_URL); return; }
这段代码看起来无懈可击，对吧？
拿用户提供的 URL，把域名替换成硬编码的后端地址，然后传下去。该做的都做了。
问题出在库上：Apache HttpComponents 那个服务器库，没有要求路径必须以 / 开头。
所以我发这个请求：
GET @burp-collaborator.net/ HTTP/1.1Host: newrelic.comConnection: close
上面那段代码就把它重写成了 http://[email protected]/，然后把请求送到了我这边。
还是老规矩，顺着这个洞我摸到了一大批内部内容，包括没做认证的管理面板，还有一些让人费解的内部笑话。
New Relic 不发赏金。但得夸他们一句：他们在公共假日里补得飞快，还把这个底层库问题报给了 Apache HttpComponents，后来也修掉了。所以用 Apache HttpComponents 的同学不用慌。
不过这类洞真的不是常识。
2011 年，同样的 payload 在 Apache mod_rewrite 上就灵过一次。而除了 New Relic，我还在17 台不同的 Yahoo 服务器上打通过它，又拿了8,000 美元。
五、隧道：把自己藏进 Tor 里 🕳️
用 @ 构造误导性 URL 这个经常被忽略的能力，用处比想象的多。但并非所有系统都吃这一套，所以我换了个变体：
GET xyz.burpcollaborator.net:80/bar HTTP/1.1Host: demo.globaleaks.orgConnection: close
思路是：有洞的主机可能会把请求送到 public-backendxyz.burpcollaborator.net，而这个名字会被我的通配符 DNS 接住。
我实际收到的东西，完全出乎意料——一批来自完全不同 IP、大小写乱七八糟的 DNS 查询：
xYZ.BurpcoLLABoRaTOR.neT. 来自 89.234.157.254 Xyz.burPColLABorAToR.nET. 来自 62.210.18.16 xYz.burpColLaBorATOR.net. 来自 91.224.149.254
GlobaLeaks 正在用 Tor2web 把进来的请求路由到 Tor 隐藏服务，为的是藏住自己的物理位置。
而 Tor 出口节点有个很冷门的安全机制：它会随机化 DNS 查询的大小写，用来提升 DNS 的安全性。这个机制导致我的 Collaborator 服务器拒绝回复，于是触发了一连串的重试。
这个洞的影响很难量化。所有请求都走 Tor，所以它没法被用来访问任何内网服务。
但它是一种异常好用的”甩锅”方式：拿别人的基础设施去打第三方。GlobaLeaks 是个举报平台，很可能不留日志，到最后这口锅说不定就落在它头上。另外，让一台 Web 服务器通过 Tor 去连接恶意站点这件事本身，就已经打开了一大片攻击面。
六、给猎人的五条提醒 🧠
- 输入变形不是噪音，是情报。 服务端怎么曲解你的输入，直接告诉你它是怎么拼 URL、怎么做规范化的。
@是老古董，但没退休。 用户名/密码分隔符这套解析规则，和现代 URL 库之间的认知差一直存在。- 看代码”对不对”没用，要看它依赖的库”做了什么假设”。 New Relic 那段代码逻辑完全正确，栽在库没校验路径格式上。
- WAF 不是边界。 Incapsula 那次，我是靠它自己的解析宽容度摸到了后端真实位置。
- 看到一个平台不落地、全走 Tor，第一反应应该是”它为什么需要藏”。
下一篇是这组研究里最出乎我意料的部分：我发往俄罗斯的请求，从英国回来了。顺着这条线，我做了一次全互联网 traceroute，然后看清了我自己家的 ISP 在干什么。
写到这里，照例求个三连。
这一篇里的每一条请求，我都在 Burp 的 Repeater 里反复试过。如果它让你下次看见一个目标”前后端分离、域名五六个”的时候，会多留个心眼——那这些晚上就没白花。
觉得有用，帮我点个**「赞」和「在看」，让更多挖洞的朋友刷到；顺手「转发」给群里那几个做后端、写网关的兄弟，第四节那段 Java 代码值得他们多看两眼；还没「关注」的朋友点个关注，下篇是最有意思的一篇，只发在这里；也欢迎「推荐」**给身边做安全的朋友，一起把”请求该被送到哪里”这件事，问得再细一点。
#HTTP隐藏攻击面 #SSRF #反向代理 #URL解析 #漏洞赏金 #赏金猎人 #Web安全 #渗透测试 #漏洞挖掘 #经验分享
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：升斗安全 升斗安全XiuXiu 升斗安全XiuXiu《一个 @ 符号，就能让代理把我送进别人家的内网》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论