前言
之前我做了一个给我们班级用的网页系统，叫作 ClassIntra，简单来说，它就是一个跑在网页上的“操作系统”，基本功能都有，如果想的话还可以自己写一个应用。班里同学一般从班级资料里的入口进，用得最多的应用是聊天室和社区。
今年 7 月 9 号，也就是放暑假前的一天，这个进入方法突然失效了，网址输进去，页面就显示无效的响应。暑假里我试了不少方法，一直都没什么进展。
将近两个月的摸查，已经能够基本确定原理和绕过方式，但因为没有条件，所以不知道具体是在哪一环拦截。如果后续有时间了，就把这个坑填上，希望这篇文章能帮助到有同样需求的同学。
拦截原理
在 40 网段里直接访问自己部署的服务，比如 http://192.168.40.90:9001，页面显示的不是常见的连接被拒绝，而是无效的响应。这两个提示看着差不多，来源却完全不同：连接被拒绝是网络层真的拒绝了；无效的响应是有人伪造了一个空响应回来，也就是说拦截发生在浏览器内部，服务器那边根本收不到任何请求。
我把这道过滤完整测了一遍，结论是：它拦的不是白名单以外的网站，而是一张为了课堂相关 IP 地址写死的黑名单，里面只有三个地址。
匹配方式是纯字符串比对，漏洞很明显。下面先讲规则，再讲一下怎么绕过。
过滤规则
浏览器发出的每个请求，都会先过一道判定。判定看的是网址里 http:// 后面、第一个 / 之前的那一段（authority），形如 用户名@主机:端口。规则只有几条：
- 黑名单里只有三个 IP：
192.168.40.1（网关）、192.168.40.90（超脑）、192.168.125.1（课堂互动网关）。在它的职责里，这个黑名单以外的地址是一律放行的，也就是说，这个黑名单和管控系统的白名单是互不干扰的，不是同一套。 - 匹配是纯字符串子串比对，不做 IP 解析。比如
192.168.40.100也会被拦，因为192.168.40.1是它开头的子串。名单是手工写的，/24这种网段写法不会被展开，连网络地址本身都会被当成字面量拦下来。 - 不分端口、不分协议通道：三个地址的所有端口都拦，顶层导航、XHR、WebSocket 走同一套判定。
- 大小写不敏感。
还有一个关键点：过滤看到的是请求发出前的原始网址，不是真正发出去的那个。网页里的 fetch、图片、脚本发出请求时会自己把网址里的用户名部分剥掉，但过滤看的是剥之前的字符串。这个错位就是绕过的口子。
怎么绕过
方式一：网址前面加一段任意字符
@ 前面那段（userinfo）是 URL 规范里给登录凭据预留的位置，现在的网站基本不用了。而这道过滤有个特点：只要 @ 前有内容，它只检查那一段，完全不看后面的主机名。
所以访问自己部署的服务，书签存成：
http://a@192.168.40.90:9001/@ 前任意非空字符都行，实测一个字符 a 就够，请求 64ms 内到达。浏览器直接打开、页面里的 XHR、WebSocket 都能走。代价：fetch 构造时会直接报错（浏览器不允许给带凭据的 URL 发 fetch），所以基于 fetch 的库会失效（axios 不受影响，它走 XHR）；图片和脚本标签会被浏览器剥掉凭据，走不了这条；刷新后地址栏会被还原，要重新拼一次。
方式二：用一个不含点分四段的域名
过滤对主机名里嵌着 IP 形状字符串的网址会按 IP 查，但主机名是普通域名、只是解析到内网地址的，直接放行。比如 nip.io 的横线写法：
http://192-168-40-90.nip.io:9001/这种域名形态是完整解：fetch、绝对路径、图片、脚本、WebSocket 全部恢复原生行为，客户端不用改任何东西。不止这一台，任何不含点分四段、解析到内网地址的域名都一样。
方式三：IPv6 映射写法（备用）
http://[::ffff:192.168.40.90]:9001/也能通。浏览器会把这种写法规范化成十六进制，点分四段消失，黑名单就匹配不上了。这个形态下页面里的相对路径请求也都能过，可以当完整入口。
试过不行的路
给服务器网卡加 192.168.40.100 别名来访问，这个不行，因为黑名单是子串匹配，40.100 开头的 40.1 会被连坐，照样会被拦。
注意事项
- 探测和访问在目标侧零痕迹：软拦不产生真实网络请求，服务器日志里不会出现被拦的访问。
- WebSocket 会留痕：WS 是唯一会把凭据原样带到服务端的通道，服务端能看到完整来源，用之前先掂量一下。
- 结论有快照时效：规则基于当前策略和设备实测，厂商如果升级过滤，用三个探针就能快速回归（见仓库报告 DP5/29/32）。
验证的完整数据（62 个探针逐项判读、判定规则、模型演进过程）在完整测试报告里：03-完整测试报告，原始日志在 records/。
发表回复