Invoke-Expression替代方法安全性探讨：是否更安全及原因

一、Invoke-Expression的危险性根源 #

Invoke-Expression本身没有“内部缺陷”，它的危险完全来自于直接将任意字符串作为PowerShell代码执行的特性——只要输入的字符串被篡改或包含恶意内容，就会直接在当前作用域执行恶意代码。它把“字符串解析为代码”和“立即执行”这两步合并成了一个操作，且没有任何额外的安全校验，这才是它被视为高危命令的核心原因。

二、关于作用域的验证 #

你对执行失败原因的判断是正确的：

• & $ScriptBlock：调用操作符默认在新作用域执行，创建的类仅存在于子作用域，父作用域无法访问
• $ScriptBlock.Invoke()：脚本块的Invoke()方法同样在新作用域执行
• Invoke-Command $ScriptBlock：不带-NoNewScope参数时，默认在新作用域执行

以上方式执行后，当前作用域无法获取定义的psMessages类，因此会出现“执行失败”的现象。

三、你所用方法的安全性对比 #

你提到的两种创建脚本块再执行的方式，和Invoke-Expression的危险等级本质相同：

1. [System.Management.Automation.Language.Parser]::ParseInput(...).GetScriptBlock() 与 [scriptblock]::Create()：这两个方法都是将字符串解析为可执行的脚本块，本质上和Invoke-Expression的“字符串转代码”步骤完全一致——如果输入的字符串包含恶意代码，解析后的脚本块同样会携带恶意逻辑。
2. 后续用. $ScriptBlock 或 Invoke-Command -NoNewScope $ScriptBlock 在当前作用域执行，也和Invoke-Expression的“本地作用域执行”效果一致。

唯一的区别是你把“字符串转脚本块”和“执行”分成了两步，而Invoke-Expression是一步完成，但这并没有降低安全风险——只要输入的字符串不可信，两种方式都会执行恶意代码。

四、更安全的实现方式 #

如果要实现“定义继承C#类的PowerShell类”的需求，更安全的思路是避免从字符串动态解析代码，直接在脚本中静态定义类：

# 先通过Add-Type创建C#基类
Add-Type @"
public class csMessages {
    public event System.EventHandler MyEvent;
}
"@

# 直接静态定义PowerShell子类，无需字符串转脚本块
class psMessages : csMessages {
    # 这里编写类代码，例如添加触发事件的方法
    void TriggerEvent() {
        MyEvent?.Invoke(this, [EventArgs]::Empty);
    }
}

如果必须动态生成类代码（比如类内容需要根据运行时数据调整），只能用动态解析的方式，但要做到以下几点降低风险：

• 严格校验输入的字符串内容，只允许预期的语法和内容，比如仅允许添加指定的方法、属性，过滤Invoke-Expression、iex等危险关键字
• 尽可能缩小动态代码的范围，比如只动态生成类的内部方法，而非整个类定义
• 避免在高权限上下文执行动态生成的代码

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