Python exec()的安全性探讨：如何绕过变量保护机制-Python教程-PHP中文网

Python exec()的安全性探讨：如何绕过变量保护机制

霞舞

发布： 2025-10-13 13:20:32

原创

890人浏览过

Python exec()的安全性探讨：如何绕过变量保护机制

本文深入探讨了python `exec()`函数在尝试保护变量时的固有安全性问题。通过一个模拟受控执行环境的示例，我们演示了即使在严格限制`globals`和`locals`的情况下，恶意代码仍能通过闭包机制直接修改`nonlocal`变量。文章强调，`exec()`本质上无法提供可靠的沙箱环境，并揭示了其更广泛的安全隐患，警示开发者避免将其用于敏感或不受信任的代码执行。

在Python编程中，exec()函数提供了一种动态执行字符串形式代码的能力。有时，开发者会尝试利用exec()来构建一个受控的执行环境，例如通过限制其可访问的全局（globals）和局部（locals）变量，以期实现某种程度的安全沙箱。然而，这种方法往往无法提供真正的安全性，尤其是在涉及变量保护时。

模拟受控执行环境

考虑一个旨在限制外部代码只能通过特定函数修改内部变量的场景。以下代码定义了一个controlled_exec函数，它试图创建一个隔离的执行环境：

def controlled_exec(code):
  x = 0
  def increment_x():
    nonlocal x
    x += 1

  # 移除所有全局变量，包括内置函数
  globals_dict = {"__builtins__": {}} 
  # 只暴露 increment_x 函数
  locals_dict = {"increment_x": increment_x} 

  exec(code, globals_dict, locals_dict)

  return x

登录后复制

在这个设计中，controlled_exec函数初始化了一个局部变量x，并定义了一个嵌套函数increment_x来递增x。increment_x使用了nonlocal关键字，表明它操作的是外部（但非全局）作用域中的x。exec()被调用时，globals_dict被清空，locals_dict只包含increment_x。理论上，这应该能确保外部代码只能通过调用increment_x()来影响x的值。

例如，执行以下代码会得到预期的结果：

立即学习“Python免费学习笔记（深入）”；

# 返回 2
result = controlled_exec("""\
increment_x()
increment_x()
""")
print(f"Final x value: {result}") # Output: Final x value: 2

登录后复制

绕过变量保护：闭包的利用

尽管上述尝试看似能够保护x，但实际上，x的值仍然可以被exec()执行的代码任意修改。其关键在于对Python闭包（closure）机制的理解和利用。

当increment_x函数被定义时，由于它引用了其外部作用域中的x（通过nonlocal x），increment_x就形成了一个闭包。这个闭包“捕获”了x变量，并将其存储在函数的__closure__属性中。__closure__是一个元组，包含了一系列cell对象，每个cell对象都封装了一个被闭包引用的外部变量。cell对象的实际内容可以通过其cell_contents属性访问和修改。

因此，即使exec()的代码无法直接访问x，它却可以访问到increment_x函数本身，进而通过increment_x.__closure__来间接操作x。

以下代码演示了如何利用这一机制来修改x的值：

AssemblyAI

转录和理解语音的AI模型

查看详情

def controlled_exec_demo(code):
  x = 0
  def increment_x():
    nonlocal x
    x += 1
    print(f"Inside increment_x, x={x}") # 添加打印以便观察

  globals_dict = {"__builtins__": {}}
  locals_dict = {"increment_x": increment_x}

  exec(code, globals_dict, locals_dict)

  return x

print("--- Demonstrating variable modification ---")
result = controlled_exec_demo("""\
increment_x()
increment_x.__closure__[0].cell_contents = -100 # 直接修改 x 的值
increment_x()
""")
print(f"Final x value after modification: {result}")

登录后复制

执行上述代码，输出如下：

--- Demonstrating variable modification ---
Inside increment_x, x=1
Inside increment_x, x=-99
Final x value after modification: -99

登录后复制

从输出可以看出，在第二次调用increment_x()之前，x的值已经被修改为-100，导致后续递增操作从-100开始。这明确证明了即使在限制了globals和locals的情况下，exec()执行的代码仍然能够绕过预期的变量保护机制。

exec()的深层安全隐患

通过闭包修改nonlocal变量只是exec()安全问题的一个温和示例。实际上，exec()在设计上就不是一个安全的沙箱工具。一旦允许执行任意Python代码，攻击者几乎可以为所欲为。

重新访问内置函数： 即使像示例中那样尝试通过globals = {"__builtins__": {}}来移除内置函数，执行的代码仍然可以通过其他途径重新获取它们。例如，任何函数对象都有一个__globals__属性，指向其定义时的全局命名空间。因此，可以通过increment_x.__globals__['__builtins__']重新获得对所有内置函数的访问权限。这意味着，像open()、eval()等危险函数仍然可以被调用。
任意代码执行： 能够执行任意Python代码，意味着攻击者可以：
- 读取、写入或删除文件系统上的任何文件。
- 发起网络请求，下载恶意软件或泄露敏感数据。
- 终止进程，甚至修改系统配置。
- 利用Python解释器中的其他漏洞。

简而言之，exec()执行的代码与宿主程序拥有相同的权限和能力。试图通过限制globals和locals来“保护”它，就像试图用薄纸板围住一个猛兽。

结论与安全建议

exec()不适合沙箱化： exec()函数不应被视为一个安全的沙箱机制，不适用于执行来自不受信任来源的代码或保护敏感变量。
避免在生产环境使用： 在生产环境中，应极力避免使用exec()来执行用户输入或任何不可信的代码。
考虑替代方案： 如果确实需要执行动态代码，应考虑更安全的替代方案：
- 专用沙箱库： 使用经过安全审计的第三方沙箱库，它们通常通过更复杂的机制（如限制系统调用、资源配额）来隔离代码。
- 独立的进程或容器： 将不受信任的代码放到一个完全隔离的进程、虚拟机或Docker容器中执行，这是最可靠的隔离方式。
- 有限的DSL（领域特定语言）： 设计一个高度受限的领域特定语言，并编写一个解析器和解释器来执行它，而不是直接执行Python代码。
重新评估设计： 在很多情况下，需要使用exec()的需求本身就可能暗示了设计上的缺陷。重新审视需求，看是否可以通过其他更安全、更结构化的方式实现相同的功能。