嵌入式 IronPython 安全性答案

【问题标题】：Embedded IronPython Security嵌入式 IronPython 安全性
【发布时间】：2012-06-02 07:05:12
【问题描述】：

我将 IronPython 嵌入到我的游戏引擎中，您可以在其中将脚本附加到对象。我不希望脚本能够随时访问 CLR，因为那样他们几乎可以做任何事情。

拥有随机脚本，尤其是从互联网下载的脚本，能够打开互联网连接、访问用户硬盘或修改内部游戏状态是一件非常糟糕的事情。

通常人们只会建议“使用单独的 AppDomain”。但是，除非我严重错误，否则跨 AppDomains 很慢。非常慢。对于游戏引擎来说太慢了。所以我正在寻找替代方案。

我考虑编译一个自定义版本的 IronPython，它会阻止您导入 clr 或任何命名空间，从而将其限制为标准库。

我宁愿选择的选项如下：

__builtins__.__import__ = None #Stops imports working
reload = None #Stops reloading working (specifically stops them reloading builtins
          #giving back an unbroken __import___!

我在另一个堆栈溢出帖子中读到了这个。假设我没有将 __builtins__._import__ 设置为 none，而是将其设置为允许您加载标准 API 的自定义函数。

问题是，使用上面概述的方法，脚本是否有任何方法能够访问 clr 模块、.net BCL 或其他任何可能做坏事的东西？还是我应该修改源？第三种选择？

【问题讨论】：

标签： c# security embed ironpython

【解决方案1】：

保证它的唯一方法是使用 AppDomain。我不知道性能受到什么影响；这取决于你的用例，所以你应该先测量它以确保它实际上太慢了。

如果您只需要一个尽力而为的系统，并且脚本不需要导入任何东西，并且您从主机提供了它们需要的所有对象，那么您的方案应该是可以接受的。您还可以避免发布 Python 标准库，这样可以节省一些空间。

您将需要检查其余的内置程序是否有任何可能与外界对话的内容；想到open、file、input、raw_input 和execfile，但可能还有其他人。 exec 也可能是一个问题，因为它是一个关键字，如果那里有开口，关闭它可能会比较棘手。永远不要低估一个坚定的攻击者的能力！

【讨论】：

通常我不会费心去费力，因为如果他们的本地计算机上有 .exe/.dll，他们无论如何都可以修改它。但是最好有游戏地图的脚本，可以下载。
@Programmdude 你在这个答案中做了什么？ AppDomain 或有您自己的自定义内置导入？如果是内置导入，你是如何填充它的？我想通过尝试删除 __import__ 变量来尝试类似的方法。 var scope = _engine.GetBuiltinModule(); scope.RemoveVariable("__import__")

【解决方案2】：

我之前在应用程序中嵌入了 Iron Python，并分享了类似的安全问题。我为帮助降低风险所做的事情是为脚本运行时创建特殊对象，这些对象本质上是围绕我的核心对象的包装器，仅公开“安全”功能。

仅为脚本创建对象的另一个好处是，您可以使用帮助函数优化它们以进行脚本编写，从而使您的脚本更加简洁和整洁。

Appdomain 与否，没有什么能阻止某人在他们的脚本中加载外部 .py 模块......这是您为灵活性付出的代价。

【讨论】：

与其说是加载外部 .py 模块，不如说是加载内置的 clr 模块并使用反射来访问它们不应该访问的东西。使用反射，他们理论上可以导入对文件系统和网络的访问，因此他们可以轻松下载病毒或木马。全部通过旨在以易于使用的方式扩展游戏或应用程序的脚本。
这里只是从臀部拍摄：如果您将“审查”模块添加到脚本导入函数中，该模块将脚本加载到某种沙箱中，然后检查哪些程序集已加载。这样，您可以针对黑名单/白名单引用程序集，并且只允许导入“安全”脚本