本文探讨python `exec()`函数在尝试构建受控执行环境时面临的安全挑战。通过一个示例函数，我们展示了即使在严格限制全局变量和内置函数的情况下，执行代码仍能直接访问并修改外部闭包变量。这揭示了`exec()`固有的不安全性，强调了在生产环境中避免执行不可信代码的重要性，并详细分析了绕过变量保护的机制。
引言：exec()与受控执行环境的尝试
Python的exec()函数允许动态执行字符串形式的Python代码，这在某些场景下提供了极大的灵活性。然而，这种灵活性也带来了潜在的安全风险，尤其是在执行不可信代码时。为了解决这一问题，开发者有时会尝试构建“沙箱”环境，以限制被执行代码的能力。
考虑以下controlled_exec函数，它旨在提供一个受控的代码执行API。其设计目标是：
隔离执行环境，移除所有全局变量和内置函数。仅暴露一个名为increment_x的函数，该函数用于递增一个内部变量x。通过返回x的值，期望能够统计increment_x的调用次数。
def controlled_exec(code): x = 0 def increment_x(): nonlocal x x += 1 # 尝试移除所有全局变量和内置函数 globals = {"__builtins__": {}} # 仅暴露 increment_x 函数 locals = {"increment_x": increment_x} exec(code, globals, locals) return x# 预期行为示例# print(controlled_exec("""# increment_x()# increment_x()# """)) # 应该返回 2
这个设计看起来似乎能有效限制被执行代码的行为，使其只能通过increment_x()间接影响x的值。然而，Python的动态特性使得这种沙箱机制远比想象中脆弱。
突破沙箱：直接操纵闭包变量
尽管controlled_exec函数试图通过限制globals和locals来隔离执行代码，但它无法阻止被执行代码直接访问和修改闭包（closure）中的变量。increment_x是一个嵌套函数，它通过nonlocal x声明来引用外部函数controlled_exec中的x变量。在Python中，这种非局部变量是通过“cell”对象实现的，这些cell对象存储在闭包的__closure__属性中。
立即学习“Python免费学习笔记（深入）”；
攻击者可以利用这一特性，直接访问increment_x函数的__closure__属性，进而修改其内部的cell对象内容，从而绕过increment_x函数本身，直接修改x的值。
以下代码演示了如何实现这一攻击：
def controlled_exec(code): x = 0 def increment_x(): nonlocal x x += 1 print(f"当前 x 的值: {x}") # 添加打印以便观察 globals = {"__builtins__": {}} locals = {"increment_x": increment_x} exec(code, globals, locals) return x# 攻击示例：在执行代码中直接修改 xprint("--- 执行攻击代码 ---")result = controlled_exec("""increment_x() # x 变为 1# 直接访问闭包，修改 x 的值increment_x.__closure__[0].cell_contents = -100 increment_x() # x 从 -100 变为 -99""")print(f"最终 x 的值: {result}")# 预期输出：# 当前 x 的值: 1# 当前 x 的值: -99# 最终 x 的值: -99
原理分析：
百宝箱
百宝箱是支付宝推出的一站式AI原生应用开发平台，无需任何代码基础，只需三步即可完成AI应用的创建与发布。
279 查看详情 
increment_x是一个内部函数，它捕获了外部函数controlled_exec的局部变量x。在Python中，当一个内部函数引用外部函数的非局部变量时，这些变量会被封装在一个cell对象中。这个cell对象可以通过内部函数的__closure__属性访问。__closure__是一个元组，包含所有捕获的cell对象。在本例中，increment_x.__closure__[0]就是包含x变量的那个cell对象。cell对象有一个cell_contents属性，可以直接读写其封装的值。
通过这种方式，被执行的代码完全绕过了increment_x的逻辑，直接操纵了x变量，将其设置为任意值（例如-100）。
exec()的固有不安全性与沙箱的局限
上述的变量操纵只是exec()固有不安全性的一个温和示例。事实上，无论你如何尝试限制exec()的执行环境，它都极难被真正地“沙箱化”。被执行的任意Python代码拥有与编写它的代码相同的访问和修改Python解释器状态的能力。
即使你尝试从globals中移除__builtins__，攻击者仍然有办法重新获取它们。例如，通过已暴露的increment_x函数，可以访问其__globals__属性，进而找到原始的__builtins__：
# 攻击者在 exec() 中可以执行的代码片段# 重新获取内置函数original_builtins = increment_x.__globals__['__builtins__']# 现在可以使用任何内置函数，例如 open()# file = original_builtins['open']('/etc/passwd', 'r')# print(file.read())
这仅仅是数十种潜在利用方式中的一种。exec()函数的设计初衷并非用于执行不可信代码，因此不提供任何内建的安全机制来限制其能力。
更严重的后果：能够修改一个整数变量x只是冰山一角。被传递给controlled_exec的代码可以执行远比这更具破坏性的操作，例如：
文件系统操作： 删除、修改、读取任何文件（如果Python进程有相应权限）。网络通信： 下载恶意软件、向外部服务器发送敏感数据。系统命令执行： 调用os.system()或subprocess模块执行任意操作系统命令。内存篡改： 访问和修改其他对象的内部状态。
总结与注意事项
通过上述分析，我们可以得出以下结论：
exec()是高度危险的： 永远不要使用exec()来执行来自不可信来源的Python代码。它无法被有效沙箱化，即使是看似严格的限制也容易被绕过。闭包的内部机制： Python的闭包通过cell对象实现非局部变量的共享，这些cell对象可以直接通过函数的__closure__属性访问和修改。这是Python语言设计的一部分，而非缺陷。沙箱的复杂性： 构建一个真正安全的Python沙箱是一个极其复杂且几乎不可能完成的任务。因为它需要限制Python解释器本身的能力，这通常需要修改解释器核心或使用更高级的虚拟化技术。
建议：
避免使用exec()： 在处理用户输入或外部代码时，应优先考虑使用更安全的替代方案，例如：配置解析器： 如果只是需要配置，使用json、yaml、ini等格式。模板引擎： 如果是生成内容，使用Jinja2等模板引擎。有限的DSL（领域特定语言）： 设计一个非常有限的自定义语言，并通过解释器安全地执行。权限最小化： 如果确实需要执行动态代码（例如在受控的开发环境中），确保运行Python进程的用户拥有最小化的系统权限。考虑第三方沙箱库： 某些第三方库（如RestrictedPython）尝试提供更安全的exec()环境，但它们通常也有自己的限制和潜在漏洞，并且不能提供绝对的安全保证。
总之，对于任何涉及执行不可信代码的场景，exec()都应被视为一个巨大的安全隐患。理解其工作原理和限制，是编写安全、健壮Python应用程序的关键。
以上就是Python exec()的沙箱限制：变量操纵与安全漏洞分析的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/598462.html
微信扫一扫 
支付宝扫一扫 
