为什么eval()在web编译器中不起作用?

2021-04-11 23:14:49 发布

您现在位置:Python中文网/ 问答频道 /正文

当我试图提交包含eval()函数的代码时,所有像pythontutor.comprogrammr.comcoursera.orgautotester等的web编译器都返回了一个名称错误。为什么不在web编译器上实现这个函数?在

3条回答
网友
1楼 ·

一个eval函数肯定会被滥用,这是一个安全风险。在

网友
2楼 ·

代码执行可以在多个级别上受到限制。限制代码功能的最强大的工具是AST检查和AST修改。Python代码被解析、标记化、转换为抽象语法树,最后对抽象语法树进行验证和修改。在

Eval和exec可能会被滥用以在AST检查周围偷偷地使用代码。因为在线示例不需要这个特性,所以简单地省略了它。在

网友
3楼 ·

我要在这方面刺一刀:

编辑

我不喜欢承认我错了,但在这种情况下,我想我必须承认。

我将指出,您仍然是以任何方式执行使用代码,所以您需要实际保护解释器。我仍然认为,“如果解释器中存在这些操作,尝试黑名单,甚至白名单都没有任何意义”,因此阻止^{{cd1>}和^{cd2>}只会带来一些小好处。

关键点如下:

Python导师的制作人执行了从外部传递给他们的代码。尽管阻塞了许多东西,包括^{{cd1>},因为它们允许执行外部代码,但我发现了一个漏洞。目前我只导入了一个被阻止的模块,但是读取源代码这也允许我做无限的IO。

进一步编辑:我已经联系了Python导师的所有者,他说他也知道,这种保护也存在于较低的水平。所以这不是一个剥削,但这主要是因为有保护在“较低的水平”。你就是这样想防范攻击,而不是黑名单。

进一步,进一步编辑:我已经调低了Python导师,虽然站点似乎又重新启动(不起作用,只是上升),因为我正在查看是否可以通过我的这种利用我的东西读/写任何东西(应业主郭菲利浦的要求)。看来我至少可以打破网站:/。对不起,这是个意外。但是,它确实证明运行不可信代码是危险的,这是我一直在说的。

然而,问题是关于意图,而不是阻塞{cd1>}是否确实有区别。

读取http://pgbovine.net/projects/pubs/guo-sigcse-preprint_2012-11-13.pdf,即

Since the backend is running untrusted Python code from the web, it implements sandboxing to prevent the execution of dangerous constructs such as eval, exec, file I/O and most module imports (except for a customisable whitelist of modules such as math).

我不会承认,我不该承认你应该如何治疗^{cd1>}和^{cd2},但我错了网站的所有者认为你应该做什么(尽管他承认你也知道你也需要沙箱)。


我以前写的:

首先,几乎与安全无关。默默无闻的安全永远不会起作用,尝试是件愚蠢的事情。通过查找动态语言对函数的调用,您不能黑名单坏函数。一个容易被蒙蔽的例子

import os; while True: os.fork()

会是

^{pr2}$

所以没有保护。我要再说一遍:如果解释器中存在这些操作,那么尝试黑名单,甚至白名单都允许执行操作。这意味着,任何东西都可以到达^{cd2>},而不需要eval,因此阻塞^{cd2>}为您提供了no安全性。


我认为真正的原因是这些不是典型的Python编译器解释器。代码所做的大部分工作都被推到Javascript或其他一些尴尬的平台上。

如果您深入检查代码,您会发现在编译到字节码时,某些东西会被硬编码,例如名称绑定。当运行诸如“eval”这样的事情时,您不能只在内联运行代码,必须编译并动态地从作用域中提取内容。支持目标语言中的这种活力是一项具有挑战性的任务,作家们可能只是不认为这是值得做的。

如果代码是在云中编译并在本地执行的:^{cd2>}因此必须往返于服务器才能工作,则这一点尤为如此!这不是一个明智的行动。

我想是这样,虽然我不知道这东西是如何实现的。

相关问题