哪些内置函数不应由不受信任的用户运行？
我正在创建一个 corewars 类型的应用程序，该应用程序在 django 上运行，并允许用户上传一些控制其角色的 python 代码。现在，我知道这个问题的真正答案是，只要我从不受信任的用户那里获取代码输入，我就会遇到安全漏洞。我只是想尽可能地降低风险。以下是一些我想到的：
__import__（我可能还会进行一些 ast 扫描以确保没有任何 import 语句）openfile< /code>inputraw_input
还有其他我遗漏的吗？
I'm creating a corewars type application that runs on django and allows a user to upload some python code that will control their character. Now, I know the real answer to this is that as long as I'm taking code input from untrusted users I'll have security vulnerabilities. I'm just trying to minimize the risk as much as possible. Here are some that spring to mind:
__import__(I'll probably also do some ast scanning to make sure there aren't any import statements)openfileinputraw_input
Are there any others I'm missing?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
在 http://wiki.python.org/ 上有很多关于限制 Python 的一般做法的答案moin/SandboxedPython。当我前段时间查看时，Zope RestrictedPython 看起来是最好的解决方案，与白名单系统一起使用。您仍然需要注意自己的代码，以免暴露任何安全漏洞，但这似乎是最好的系统。
There are lots of answers on what to do in general about restricting Python at http://wiki.python.org/moin/SandboxedPython. When I looked at it some time ago, the Zope RestrictedPython looked the best solution, working with a whitelist system. You'll still need to take care in your own code so that you don't expose any security vulnerabilities, but that seems to be the best system out there.
既然您听起来决心这样做，我会将您链接到标准 rexec 模块，不是因为我认为你应该使用它（不 - 它有已知漏洞），但因为这可能是
让您的网络服务器受到损害您自己的受限执行框架的一个很好的起点。特别是，在“定义受限环境”标题下列出了 rexec 设计者认为相当安全的几个模块和函数；这些可能可以用作初始白名单。我还建议检查其代码是否存在您可能没有想到的其他问题。
Since you sound determined to do this, I'll link you to the standard rexec module, not because I think you should use it (don't - it has known vulnerabilities), but because it might be a good starting point for
getting your webserver compromisedyour own restricted-execution framework.In particular, under the heading "Defining restricted environments" several modules and functions are listed that were considered reasonably safe by the rexec designer; these might be usable as an initial whitelist of sorts. I'd also suggest examining its code for other gotchas you might not have thought of.
您确实需要避免 eval。
想象一下这样的代码：
这可能是最重要的一个。
You will really need to avoid eval.
Imagine code such as:
This is probably the most important one.
是的，你必须加入白名单。有很多方法可以隐藏错误的命令。
这不是最坏的情况：
最坏的情况是整台计算机获得 root 权限，而您却没有注意到它会探测您的其他计算机并记录您的密码。隔离这台机器并认为它是敌对的（DMZ，阻止它从内部和外部发起攻击等）。在不可写介质上运行 tripwire 或 AIDE，并将所有内容记录到第二台主机。
最后，正如 plash 所示，需要防范许多危险的系统调用。
Yeah, you have to whitelist. There are so many ways to hide the bad commands.
This is NOT the worst case scenario:
The worst case scenario is getting the entire machine rooted and you not noticing as it probes your other machines and keylogs your passwords. Isolate this machine and consider it hostile (DMZ, block it from being able to launch attacks internally and externally, etc). Run tripwire or AIDE on non-writeable media and log everything to a second host.
Finally, as plash shows, there are a lot of dangerous system calls that need to be protected against.
如果您不打算使用 Python 作为游戏中的语言，一种可能是使用 LunaticPython 嵌入 Lua（我建议位于 https://code.launchpad.net/~dne/lunatic-python/bugfixes）。
沙箱 Lua 比 Python 容易得多，嵌入 Lua 也比创建自己的编程语言容易得多。
If you're not committed to using Python as the language inside the game, one possibility would be to embed Lua using LunaticPython (I suggest the bugfixes branch at https://code.launchpad.net/~dne/lunatic-python/bugfixes).
It's much easier to sandbox Lua than Python, and it's much easier to embed Lua than to create your own programming language.
您应该使用白名单，而不是黑名单。如果你使用黑名单，你总会错过一些东西。即使你不这样做，Python也会在标准库中添加一个函数，你也不会及时更新你的黑名单。
您当前允许但可能不应该包括的内容：
compile< /a>evalreload（如果他们确实以某种方式访问文件系统，这基本上是import)我同意正确地做到这一点非常棘手。一个复杂的问题（其中之一）可能是用户通过另一个类中的字段访问这些函数之一。
我会考虑使用另一种隔离机制，例如虚拟机，作为替代或补充。您可以看看 codepad 是如何做到的。
You should use a whitelist, rather than a blacklist. If you use a blacklist, you will always miss something. Even if you don't, Python will add a function to the standard library, and you won't update your blacklist in time.
Things you're currently allowing but probably should not include:
compileevalreload(if they do access the filesystem somehow, this is basicallyimport)I agree that this would be very tricky to do correctly. One complication (among many) could be a user accessing one of these functions through a field in another class.
I would consider using another isolation mechanism, such as a virtual machine, instead or in addition to this. You might look at how codepad does it.