
微应用沙箱逃逸防御实战:从eval隔离到Proxy+Realm级运行时管控微前端架构中,微应用隔离是安全与稳定的生命线。但多数团队仍停留在iframe或简单 CSS/JS 命名空间隔离层面,对真实 JS 运行时逃逸(如通过window.top.eval、document.write、Function.constructor动态构造、甚至WebAssembly.Memory跨域读写)缺乏纵深防御能力。本文不讲概念,直接落地一套可嵌入 qiankun / micro-app / 混合微前端体系的轻量级沙箱增强方案,基于现代浏览器原生能力构建Realm+Proxy+Compartment三重防护层。一、为什么传统沙箱会失效?常见误区:✅ 重写window属性为只读 Proxy❌ 忽略Function('return this')()可绕过所有window代理❌ 忽略eval('this')在非严格模式下仍指向全局❌ 忽略new Function('return this')()完全脱离当前执行上下文实测验证(在主应用控制台执行):// 模拟恶意微应用代码constevilCode=`// 绕过 window Proxy:获取原始 globalThis const rawGlobal = Function('return this')(); rawGlobal.alert('沙箱已失守!'); // 动态构造函数逃逸 const ctor = rawGlobal.Function; ctor('alert("逃逸成功")')(); // WebAssembly 内存越界(需配合 wasm binary) // const mem = new WebAssembly.Memory({ initial: 1 }); // new Uint8Array(mem.buffer)[0] = 0xFF; // 可篡改主应用内存`;``` 🔍 关键结论:**仅靠`Proxy`拦截`window`不足以构建可信沙箱** —— 必须从执行上下文(Execution Context)源头隔离。 --- ## 二、Realm:浏览器原生的“进程级”隔离(Chrome 94+ / Edge 94+)`Realm`是 ECMAScript 提案(Stage 3),Chrome/Edge 已实现。它提供**完全独立的全局对象、内置构造器、原型链**,从根本上杜绝`Function`/`eval`逃逸:```ts// 创建隔离 Realm(需启用 --enable-features=ExperimentalJavascriptFeatures)constrealm=newRealm();// 在 Realm 中执行代码 → 全局对象与主应用完全无关realm.evaluate(`console.log(this === globalThis); // false console.log(typeof alert); // "undefined" console.log(Function === this.Function); // true(自有 Function)`);// 主应用无法访问 realm 内部变量console.log(realm.globalThis);// undefined(被封装)⚠️ 注意:Realm当前为实验性 API,生产环境需降级兜底(见第四节)。三、生产可用方案:Proxy + Comp