使用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 osfilename = 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命令的一部分。
Melodio
Melodio是全球首款个性化AI流媒体音乐平台，能够根据用户场景或心情生成定制化音乐。
110 查看详情
看一个安全的例子：
import subprocessuser_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 subprocessimport shlexuser_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
with
shell=True
detected. 这是最直接的警告，它会标记所有
subprocess.run()
、
subprocess.call()
等函数中使用了
shell=True
的地方。虽然这本身不一定是漏洞（如果参数都经过
shlex.quote
处理），但它是一个高风险的信号。B607:
start_process_with_partial_path
detected. 如果你执行的命令没有指定完整的路径，而只是命令名（比如
ls
而不是
/bin/ls
），那么攻击者可能会通过修改
PATH
环境变量来执行恶意程序。B602:
subprocess
module with
shell=True
and no
shlex.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标记为警告，因为它的风险级别确实较高。所以，工具的输出需要人工的专业判断来确认。它们是提升代码安全性的重要辅助，但最终的责任和决策权还是在于开发者。
以上就是Python怎样发现不安全的shell命令拼接？的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/938130.html
微信扫一扫 
支付宝扫一扫 
