向公共方法/构造函数传递Action、Func或委托的安全问题解析

一、传递委托的安全风险到底在哪？ #

安全问题的核心在于权限上下文和执行控制权，具体可被利用的场景包括：

• 权限提升攻击：如果你的类运行在更高权限的环境（比如管理员权限的服务、ASP.NET服务器进程），外部传入的委托会以当前类的权限执行。举个实际例子：

  // 你的类（运行在管理员权限进程）
  public class MyClass { public MyClass(Action doSomething) { doSomething?.Invoke(); } }
  // 外部低权限代码
  var maliciousAction = new Action(() => System.IO.File.Delete(@"C:\Windows\System32\critical.dll"));
  var instance = new MyClass(maliciousAction);
  

  外部代码本身没权限删除系统文件，但通过委托让你的类代为执行，就成功完成了恶意操作。
• 敏感数据泄露：如果你的类调用委托时传入了内部敏感信息（比如数据库密钥、用户隐私数据），外部委托可以直接捕获并泄露这些数据。比如你示例中传入的"something"如果是用户的加密密钥，外部Action就能把它输出到日志或者第三方服务器。
• 业务逻辑破坏：恶意委托可以执行无限循环、死锁，导致你的服务崩溃；或者通过闭包捕获并修改类的内部状态，篡改正常业务流程。

二、要不要彻底禁止向类传递委托？ #

不是绝对不能用，而是要严格控制使用场景：

• 只在信任的代码范围内传递：比如同一个项目内部、经过严格审核的内部类库，别把接受委托的API暴露给外部不可信的代码。
• 加安全校验：如果必须对外提供这类API，在调用委托前检查执行上下文的权限，或者限制委托能访问的资源范围。
• 优先用接口替代：比如定义一个ISomethingExecutor接口，让外部类实现这个接口，再把实例传给你的类。这样既能约束行为，也方便做权限和逻辑校验，比直接传委托更安全可控。

三、和使用事件的代码有什么区别？ #

事件本质是封装后的委托，但两者的安全边界完全不同：

• 调用控制权不同：事件只能由定义它的类触发，外部代码只能订阅或取消订阅，不能直接调用事件委托。而你示例中传递的委托是外部传入后立即由你的类执行，外部可以主动触发这个执行流程。
• 意图不同：事件是用来通知外部“发生了某件事”，外部代码只能被动响应；而传递委托是让外部代码直接参与到你的类的内部逻辑中，风险更高。
• 滥用难度不同：事件触发时机由你的类控制，恶意代码无法随意触发来滥用权限，只能在正常业务流程中响应，安全风险更低。

比如你给出的事件代码：

var securityIssueActionOutsideOfMyControl = new Action(() => { ... });
var instance = new MyClass();
instance.MyEvent += (s, e) => securityIssueActionOutsideOfMyControl();

这里外部代码只能等MyClass内部触发MyEvent时，才会执行对应的Action，无法强制触发执行，风险远低于直接传递委托。

四、和外部直接调用委托的区别？ #

核心区别在于执行权限的上下文：

• 外部直接调用委托时，代码的执行权限是外部代码自身的权限；而你的类调用传入的委托时，执行权限是你的类所在进程/上下文的权限。
• 举个例子：外部代码是普通用户权限，直接调用删除系统文件的委托会失败；但如果把这个委托传给运行在管理员权限的你的类，你的类调用它就会成功执行删除操作，这就是典型的权限提升风险。
• 另外，外部直接调用委托时，只能访问自己能获取的数据；而你的类调用委托时可能传入内部敏感数据，导致数据泄露。

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