因此,重申您的主要关注点:
...因此可以访问我的应用程序及其当前运行的表单/方法/控件/等。
在开始使用复杂而困难的方法来加载、隔离和限制这些扩展之前,您应该了解一些关于 Windows 和 CLR 的知识。首先,在盒子上运行的任何程序都可以使用许多 Windows API 将代码注入您的进程。一旦代码被您或操作系统加载到您的进程中,访问 CLR 运行时并加载程序集和/或在现有 AppDomain 中运行代码是相当容易的。
知道这一点,您应该权衡和平衡您摘录以限制“扩展”的努力。如果我在哪里构建这样的东西,我会更关心其他事情,而不是操纵我的应用程序状态的恶意扩展代码。例如,这些是您可能会考虑的事情:
- 仅加载用户批准的扩展,允许他们控制允许的内容,并允许他们稍后在需要时撤销扩展。以 Office 或 VStudio 为例。
- 使用代码签名要求(强名称或代码签名证书)确保这些已批准的扩展未被篡改。
- 如果发现扩展程序是恶意的,请考虑撤销扩展程序远程运行的能力。
- 证明一个设备齐全的接口 API 以允许开发人员轻松实现所需的行为。如果他们很容易使用您的界面来完成他们的任务,他们就不需要“破解”。
除此之外,您真的无能为力。正如我所说,即使有上述安全措施,任何人都可以攻击您的应用程序。您主要关心的应该是不要让您的用户感到惊讶。因此,应谨慎对待您的应用程序运行的代码,但是一旦您的用户授予他们访问权限,这些扩展程序会做什么并不是您可以完全控制的事情。
这并不是说 AppDomain 隔离不会为您提供价值,它可能会;然而,恕我直言,在不限制其功能的情况下获得足够的安全限制将被证明是困难的。
更新
...但是如果您将插件加载到配置有有限权限的 AppDomain 中,它如何使用此向量?
正确,正如我在结束语中所说,您可以限制他们访问 AppDomain 中的非托管代码。这也限制了他们开发可用 Windows 体验的能力。我希望大多数 WinForms 应用程序至少使用一个 PInvoke 调用或非托管 COM 控件。施加的这种限制可能是可以接受的,如果没有更多关于他们试图提供的功能的信息,我真的不能说。
我想说的是,通过安装和批准扩展,您的用户将承担允许该扩展运行的责任。该扩展程序的作用以及它可能尝试的恶意程度不是您的责任,当然前提是您加载了正确的代码。这就是为什么我建议您将精力集中在运行已批准的代码上,而不是担心该代码在您的流程中可能会做什么。