基于浏览器的dirty克隆方案是否存在安全风险？相关规避方案是否有效？

该dirtyClone方案存在明确的安全风险，具体风险点如下： #

• 任意代码注入（XSS）风险
  该方案的核心逻辑是将待克隆对象toString()的返回值直接拼接为可执行代码，插入script标签后在当前页面的安全上下文执行。如果待克隆的函数/类来自用户可控输入，攻击者可以构造包含恶意逻辑的函数，比如在函数体中插入窃取用户Cookie、篡改页面内容、跳转钓鱼站点、调用站点敏感接口的代码，插入页面后会直接获得和站点自身脚本完全一致的执行权限，属于典型的存储型/反射型XSS攻击。
• 正则匹配绕过风险
  方案中使用/[^{]*/匹配函数/类的声明部分，规则非常简陋。攻击者可以构造特殊的函数声明，比如在函数名、参数列表中插入{、注释符、额外的可执行代码片段，绕过你的类型判断逻辑，注入预期之外的恶意代码。
• 全局作用域污染与原型链污染风险
  克隆生成的函数/类直接挂载到window全局对象上，攻击者可以构造恶意代码覆盖fetch、JSON.stringify等全局内置方法，也可以通过恶意类修改Object、Array等内置对象的原型，污染全局执行环境，影响页面所有后续代码的运行逻辑，甚至实现持久化攻击。

常见函数克隆方案的风险规避能力说明 #

针对涉及未知用户输入的场景，你提到的几类方案都无法完全规避上述安全风险：

• eval()、new Function()
  这两类方法本质也是动态解析执行字符串形式的代码，和插入script标签没有本质的安全差异，只要输入可控，攻击者构造的恶意代码字符串照样可以正常执行，完全不能规避注入风险，甚至不需要操作DOM，注入流程更简单。
• .bind()、.call()、.apply()
  这三个方法根本不属于函数克隆方案：bind()只是返回一个绑定了this指向和预设参数的原函数引用，本质上还是使用原函数实体，没有生成新的克隆函数；call()、apply()只是临时修改this指向执行原函数。首先无法满足函数克隆的需求，其次如果原函数本身是用户提供的恶意函数，调用这三个方法执行依然会触发全部恶意逻辑，没有任何安全增益。

补充说明：目前不存在可以100%安全克隆未知用户提供的函数/类的前端方案，只要涉及执行用户可控的代码逻辑，必然存在安全隐患。如果业务确实需要处理用户提供的可执行代码，必须使用严格的沙箱隔离方案，比如带安全限制的iframe、Web Worker隔离执行，禁止操作当前页面的DOM和敏感接口。

内容的提问来源于stack exchange，提问作者Ed_Johnsen