使用os.system()或subprocess.run(..., shell=true)危险的原因是它们将用户输入作为shell命令解析，易受命令注入攻击；1. 避免使用这些方式，改用subprocess并设置shell=false，参数以列表形式传递；2. 若必须用shell=true，需用shlex.quote对所有外部输入转义；3. 对输入进行白名单验证和净化；4. 遵循最小权限原则限制执行环境。例如，用户输入恶意字符会被当作参数而非命令执行，从而避免注入风险。静态分析工具如bandit可辅助识别潜在漏洞，但需结合人工审查确认。
Python要发现不安全的shell命令拼接，核心在于识别那些将不可信的用户输入直接或间接作为shell命令一部分执行的代码。这通常发生在调用
os.system()或
subprocess模块时，特别是当
shell=True参数被设置时，如果没有对输入进行严格的验证和转义，就极易引发命令注入漏洞。发现它，更多的是一种防御性编程思维和代码审计的体现，而不是某种自动检测机制。
解决方案
解决这个问题，关键在于从根本上避免不安全的拼接方式，并采取多层防御策略。
首先，最直接且推荐的方法是避免使用os.system()
和subprocess.run(..., shell=True)
。Python的
subprocess模块设计初衷就是为了更安全、更灵活地替代
os.system。当你不设置
shell=True时，
subprocess会直接执行命令，并将参数作为独立的列表项传递给程序，而不是通过shell解释器。这意味着，即使用户输入包含恶意字符，它们也会被当作普通参数，而不是命令的一部分来执行。
立即学习“Python免费学习笔记（深入）”；
其次，如果确实有非用
shell=True不可的场景（比如需要利用shell的管道、重定向等复杂特性），那么必须使用
shlex.quote()来对所有外部或不可信的输入进行严格的转义。
shlex.quote()会确保字符串被正确地引用，使其在shell中被视为单个参数，从而防止注入。但这并非万能药，它只是解决了参数注入的问题，如果命令本身就是用户可控的，那还是无解。
再者，对所有外部输入进行严格的验证和净化（Input Validation and Sanitization）是第一道防线。在任何数据进入系统或被用于构造命令之前，都应该对其进行类型、格式、内容、长度等方面的校验。最好的策略是采用“白名单”机制，只允许已知安全的字符集或模式通过，而不是试图过滤所有可能的恶意输入。
最后，遵循最小权限原则。运行外部命令时，确保其运行环境和用户权限被限制在最低限度，即使发生注入，也能将潜在的危害降到最低。
为什么直接使用os.system()
或subprocess.run(shell=True)
如此危险？
这其实是个老生常谈的问题，但总有人会踩坑。当你使用
os.system()或者在
subprocess.run()中设置了
shell=True时，Python实际上是将你提供的整个命令字符串传递给了系统的shell（比如Bash、Zsh或CMD）。这个shell会解析你给的字符串，并执行其中的命令。问题就出在这里：如果你的命令字符串中包含了任何来自用户、文件、网络等外部来源的、未经严格处理的数据，那么这些数据中的特殊字符（比如
;,
|,
&,
>,
<等）就可能被shell误认为是命令分隔符或操作符。
举个例子，假设你写了一段代码，想让用户输入一个文件名，然后用
cat命令显示文件内容：
import os
filename = input("请输入要查看的文件名：")
# 危险！如果用户输入 "file.txt; rm -rf /"
os.system(f"cat {filename}")如果用户输入的是
myfile.txt; rm -rf /，那么
os.system()执行的就不是简单的
cat myfile.txt，而是
cat myfile.txt然后
rm -rf /。这后果不堪设想。
subprocess.run(f"cat {filename}", shell=True)也会面临同样的问题。这种模式下，你把控制权几乎完全交给了外部输入，让它有机会执行任意系统命令。在我看来，这就像是打开自家大门，然后告诉所有陌生人：“随便进，随便拿！”
subprocess
模块如何安全地执行外部命令？
subprocess模块是Python处理外部命令的瑞士军刀，用得好，它就是你的安全卫士；用不好，它就是个定时炸弹。要安全地使用它，核心在于不设置
shell=True，并将命令及其参数作为列表传递。
当你不设置
shell=True（这是默认行为）时，
subprocess模块会直接执行你提供的第一个元素作为命令，而列表中的后续元素则被视为该命令的参数。在这种模式下，Python不会调用shell来解析你的命令字符串，而是直接通过操作系统API来执行程序。这意味着，任何参数中的特殊字符都只会被当作普通字符串数据，而不会被解释为shell命令的一部分。
看一个安全的例子：
import subprocess
user_input = input("请输入要搜索的关键词：")
# 安全地执行 grep 命令，用户输入被视为普通参数
try:
# command_and_args = ["grep", "-i", user_input, "/var/log/syslog"] # 假设搜索系统日志
# 为了演示方便，我们用一个简单一点的命令
command_and_args = ["echo", "用户输入是:", user_input]
result = subprocess.run(command_and_args, capture_output=True, text=True, check=True)
print("命令输出：")
print(result.stdout)
if result.stderr:
print("错误输出：")
print(result.stderr)
except subprocess.CalledProcessError as e:
print(f"命令执行失败，返回码：{e.returncode}")
print(f"错误信息：{e.stderr}")
except FileNotFoundError:
print("错误：命令未找到，请检查路径或是否已安装。")
在这个例子中，即使
user_input是
"; rm -rf /"，
echo命令也只会把它当作一个长字符串打印出来，而不会执行
rm -rf /。这就像你把一串乱码扔给一个不识字的人，他只会原封不动地念出来，而不会理解其中的“恶意”。这就是
shell=False带来的安全保障。同时，
check=True能让命令执行失败时抛出
CalledProcessError，方便我们捕获异常，而不是默默地失败。
shlex.quote
何时派上用场，它的工作原理是怎样的？
shlex.quote是Python标准库
shlex模块中的一个非常实用的函数，它主要用于当你确实需要使用
shell=True，并且需要将用户提供的字符串作为参数传递给shell命令时。它能够安全地引用字符串，使其在shell中被视为单个不可分割的参数，从而防止shell注入。
它的工作原理其实很简单：它会根据操作系统的shell规则，在字符串的开头和结尾添加引号（通常是单引号
'），并对字符串内部可能引起歧义的特殊字符（如单引号本身）进行转义。这样一来，无论用户输入什么，shell都会将其视为一个完整的、字面意义上的字符串，而不是命令或操作符。
考虑一个场景，你可能需要执行一个包含管道或重定向的复杂shell命令，而这些特性只有通过
shell=True才能方便地实现。例如：
import subprocess
import shlex
user_search_term = input("请输入要搜索的词（支持正则表达式）：")
log_file = "/var/log/nginx/access.log" # 假设日志文件路径固定
# 危险的写法（如果用户输入了恶意字符，例如：".*; rm -rf /"）
# subprocess.run(f"grep '{user_search_term}' {log_file} | wc -l", shell=True)
# 安全的写法：对用户输入进行 shlex.quote
# 注意：这里只对用户输入的搜索词进行了引用，log_file是程序内部定义的，相对安全
safe_search_term = shlex.quote(user_search_term)
command = f"grep {safe_search_term} {shlex.quote(log_file)} | wc -l" # 即使log_file是变量，也应该引用
print(f"将要执行的命令：{command}")
try:
result = subprocess.run(command, shell=True, capture_output=True, text=True, check=True)
print("匹配行数：", result.stdout.strip())
except subprocess.CalledProcessError as e:
print(f"命令执行失败，返回码：{e.returncode}")
print(f"错误信息：{e.stderr}")
except Exception as e:
print(f"发生未知错误: {e}")
在这个例子中，
shlex.quote(user_search_term)确保了
user_search_term即使包含
'、
"、
`、;
等字符，也会被grep
命令正确地当作一个整体的搜索模式来处理，而不是被shell解析为多个命令或操作符。它就像给你的用户输入穿上了一件“防弹衣”，让shell无法对其进行“解剖”。但再次强调，这只是在特定场景下的权宜之计，能不用shell=True`就尽量不用。
静态代码分析工具如何辅助发现潜在的shell注入漏洞？
手动审查代码来发现所有潜在的shell注入点，尤其是在大型项目中，是件费时费力且容易遗漏的工作。这时候，静态代码分析工具就能派上大用场了。它们不会运行你的代码，而是通过分析代码结构和模式，来识别那些可能导致安全问题的代码片段。
在Python领域，Bandit是一个非常流行的安全 linter，它在这方面做得相当出色。Bandit专门设计来查找Python代码中的常见安全漏洞，其中就包括对不安全地使用
subprocess和
os.system的检测。
例如，Bandit有几个特定的检查项（plugins）就是针对shell注入的：
-
B603:
subprocess
withshell=True
detected. 这是最直接的警告，它会标记所有subprocess.run()
、subprocess.call()
等函数中使用了shell=True
的地方。虽然这本身不一定是漏洞（如果参数都经过shlex.quote
处理），但它是一个高风险的信号。 -
B607:
start_process_with_partial_path
detected. 如果你执行的命令没有指定完整的路径，而只是命令名（比如ls
而不是/bin/ls
），那么攻击者可能会通过修改PATH
环境变量来执行恶意程序。 -
B602:
subprocess
module withshell=True
and noshlex.quote
detected. 这是更精确的检测，它会尝试判断shell=True
的使用是否伴随着shlex.quote
的缺失。
你可以将Bandit集成到你的开发流程中，比如在Git hooks中或者CI/CD管道中运行它。当它发现潜在问题时，会给出警告或错误，提示开发者去审查并修复这些代码。
使用Bandit通常很简单：
bandit -r your_project_directory
虽然这些工具非常有用，但它们并非万能。它们主要基于模式匹配，可能存在误报（false positives）或漏报（false negatives）。比如，一个经过
shlex.quote处理的
shell=True调用可能仍然会被Bandit标记为警告，因为它的风险级别确实较高。所以，工具的输出需要人工的专业判断来确认。它们是提升代码安全性的重要辅助，但最终的责任和决策权还是在于开发者。
