接受匿名方法（Action<>、Func<>）作为参数有哪些安全隐患？答案

【问题标题】：What are the security implications for accepting anonymous methods (Action<>, Func<>) as parameters?接受匿名方法（Action<>、Func<>）作为参数有哪些安全隐患？
【发布时间】：2015-03-02 07:42:21
【问题描述】：

正如标题所说：在 C# 中使用和/或传递匿名方法（Action<>、Func<>）时需要考虑哪些安全隐患？

接受Action<>/Func<> 的方法似乎是将外部代码注入程序的潜在方式。作为记录，我知道注入的方法或函数不能在任意内存访问的意义上做本质上不安全的事情，但我认为它可以允许调用代码调用例如任意 .Net 框架函数、损坏数据或以其他方式导致应用程序行为异常。

这个假设是错误的吗？

如果不是，应该怎么做才能锁定这些？此外，是否有任何方法可以验证传递给方法或函数的/Func<>，以确保它具有预期的形式或限制其对某些类型和命名空间的访问？

另外，如果我没有完全使用正确的术语，请原谅我，我还在学习。

【问题讨论】：

还请注意，您可以通过继承（通过覆盖虚拟和抽象方法）和接口实现注入恶意代码。但 SLaks 的回答也适用于这些情况。例如，System.String 类通过被密封来保护自己免受这种情况的影响。
场景是什么？同一进程中的可信代码和不可信代码用 CAS 分隔？
@usr 我真的在问是否有有场景需要担心。我在这里看到了一些解决方案，它们使用它们作为一种方式，例如，通过将属性 getter 或 setter 包装在其中一个中来将其传递给命名方法。但这感觉不正确，因为据我所知，命名方法无法保证或以其他方式确保传递的 Action 或 Func 以预期的方式运行。除非命名方法真的不在乎它的作用，否则将这些用作参数是不好的做法吗？例如。 Assert.ThrowsException().

标签： c# .net security action func

【解决方案1】：

接受Action
/Func的方法似乎是将外来代码注入程序的潜在方式

这是完全错误的。根据定义，调用您的函数并传递委托的人已经在您的程序中运行代码。
任何传递委托的代码已经可以做它想做的任何事情。在同一个 AppDomain 中不能有安全边界。（旧版本的 .Net 具有代码访问安全性，它试图这样做，但不是一个好主意）

但是，它可能会产生意外的重入，从而导致线程安全代码出现问题。

【讨论】：

我想我明白了。您是说任何可以运行的东西都可以调用代码本身，而假定的恶意代码这样做没有任何好处？假设有一个故意导致的重新进入。这会带来安全风险，还是可能会破坏程序的稳定性？如果我进入一个无限循环，那可能是我想象的一个问题。如果是这样，是否有设计建议来降低风险？例如在内部谨慎使用这些，如果公开，则彻底测试重新进入和不稳定性？
@NickBauer：同样，除非您有实际的安全边界，否则没有安全可言。见blogs.msdn.com/b/oldnewthing/archive/2014/05/29/10529251.aspx 和blogs.msdn.com/b/oldnewthing/archive/2007/08/07/…
好的，我和你在一起。但是我仍然很好奇你关于重入的意思，因为你提到了它。编辑：也就是说，不是重新进入是一个问题，但是如果允许以这种方式重新进入的窗口可能是一个问题。

【解决方案2】：

我真的在问是否有有场景

当 CAS 策略仍在使用时（例如，中等信任的 ASP.NET），当存在堆栈断言时，受信任的代码段无法安全地调用不受信任的代码。例如当

new SecurityPermission(Unrestricted).Assert()

实际上，安全检查堆栈遍历将在此时停止。这可能导致无法检测到不受信任的代码。 See the docs for Assert.

我在这里有点含糊，因为这个场景很难实现而且已经过时了。

如果同一进程内没有信任边界，则调用者已经拥有所有权力，即使没有在某处注入代码。没必要。

【讨论】：