嵌入式IronPython安全性
本文关键字：安全性 IronPython 嵌入式 | 更新日期: 2023-09-27 18:35:31
我正在将IronPython嵌入到我的游戏引擎中，您可以在其中将脚本附加到对象。我不希望脚本能够随时访问 CLR，因为那样它们几乎可以做任何事情。
拥有随机脚本，尤其是从互联网下载的脚本，能够打开互联网连接、访问用户硬盘或修改内部游戏状态是一件非常糟糕的事情。
通常人们只会建议"使用单独的应用程序域"。但是，除非我严重错误，否则跨应用程序域很慢。很慢。对于游戏引擎来说太慢了。所以我正在寻找替代方案。
我考虑编译一个自定义版本的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 或任何其他可能做坏事的事情？还是我应该修改源？第三种选择？
保证它的唯一方法是使用 AppDomain。我不知道性能打击是什么;这取决于您的用例，因此您应该首先对其进行测量以确保它实际上太慢了。
如果你只需要一个尽力而为的系统，并且脚本不需要导入任何东西，并且你从主机提供它们需要的所有对象，那么你的方案应该是可以接受的。您还可以避免发布 Python 标准库，这将节省一些空间。
您需要检查其余的内置组件，以获取可能与外界对话的任何内容; open、file、input、raw_input和execfile浮现在脑海中，但可能还有其他的。 exec也可能是一个问题，并且由于它是一个关键字，如果那里有空缺，关闭可能会更棘手。永远不要低估坚定的攻击者的能力！
我之前在应用程序中嵌入了Iron Python，并分享了类似的安全问题。为了帮助降低风险，我所做的是仅为脚本运行时创建特殊对象，这些对象本质上是围绕我的核心对象的包装器，仅公开"安全"功能。
仅为脚本创建对象的另一个好处是，您可以使用帮助程序函数优化它们的脚本，从而使脚本更加简洁整洁。
无论是否应用域，没有什么能阻止某人在他们的脚本中加载外部.py模块...... 这是您为灵活性付出的代价。