命令注入发生在哪道边界？
应用把不可信输入纳入操作系统命令，而执行机制将其中内容解释为指令语法，攻击者就可能改变原定操作。关键是数据与命令结构混在一起，不是文件名看起来奇怪，也不是任意文件上传都会执行。[1]
011 / Web 与应用 / Command Injection
只是一个文件名，为何改了执行动作？
命令注入 · Command Injection
报表工具需要知道读哪份文件，应用却把文件名拼进一整段命令。外部输入于是有机会改变命令的结构。换成独立参数后，还得继续检查：工具会不会把它当作另一项选项？
开始探索 ↓8–11 分钟
动手实验 · 场景判断 · 实用检查
动手实验 · 场景判断 · 实用检查
外来纸张进入处理机器，红色小怪随之跑向文件柜和电脑。风险在于输入被当作操作系统命令语法解释，不是任意上传文件都会执行；画面不能与 SQL 注入或普通文档宏混为一谈。
本课任务 / 命令注入
沿输入、解释器和工具参数追踪信任边界，比较避免 shell、参数分离与业务允许列表的不同效果。
- 解释数据被当作操作系统命令语法的风险
- 区分 shell 注入与工具选项注入
- 比较专用 API、参数分离及允许列表
亲手探索 / 不同条件，不同结果
把同一份输入分别交给三种调用设计。
选择正常报告名、带教学分隔标记的输入或选项式输入，比较 shell 字符串、独立参数和专用报告 API。打开已知报告允许列表，查看输入在哪一步被拒绝。所有结果都是符号演示，不执行命令。
攻击机制工作台 · 封闭离线模型
文件名在哪一步变成了指令？
查看一份虚构报告。只使用三个预设符号输入，比较解释器、参数和业务允许清单；这里没有真正的终端或命令执行。
本次输入：report.txt ; 教学附加动作
已运行 0 次；累计符号操作 0 次。
尚未检查当前条件。修改选择会清除旧结论；保留的状态可在工作台查看。
只模拟一个预定义分隔符和工具选项，不是通用 shell 解析或转义器。独立参数不能替代工具选项验证；避免 shell 后，仍须校验业务数据和限制权限。
随手查 / 把理解带回实际工作
理解机制之后，检查这些细节。
实验是简化模型。真实环境需要明确业务规则、验证失败路径，并持续维护配置与证据。
01 / 实用细节
先追踪完整的数据去向
检查外部输入从入口到调用位置经过了什么处理，以及最后由谁解释。前端校验、隐藏字段或文件扩展名都不能单独建立服务端边界；应以实际调用接口与最终参数为证据，而不是只搜索某个危险字符。[1]
02 / 实用细节
能使用专用功能，就不拼命令
读取指定报表如果可以通过受控的报告查询 API 完成，就不必为此引入 shell 语法。这样移除一类解释步骤，同时仍需核验目标是否存在、是否属于允许集合以及请求者是否有权访问。[1]
03 / 实用细节
独立参数保护的是结构分隔
在支持的进程接口中明确传递程序与参数，不再把用户输入拼成整段 shell 字符串。本例分隔标记在独立参数路径中只是同一参数里的数据；这不表示所有语言的字符串执行接口都有相同安全语义。[1]
04 / 实用细节
工具自己的选项也能改变行为
一个看似文件名的参数，可能被目标工具解释为选项而改变原任务。控制允许的参数与值，必要时使用该工具明确支持的选项终止方式；不能在不了解工具语义时假设加上一个分隔符就对所有程序有效。[1]
05 / 实用细节
允许列表按业务定义，而非猜坏字符
练习只允许固定的已知报告名，能在调用前拒绝未批准输入，同时保留合法报告查询。真实验证应限定必要的值、类型、格式和长度，并与安全调用方式一起使用；删掉分号或采用 HTML、SQL 转义都不能普遍修复命令注入。[1]
06 / 实用细节
权限和隔离限制影响，仍要修复入口
让执行身份仅访问任务所需资源，可以减少执行被改变后的影响，但它不会把不安全拼接变安全。低权限进程仍可能接触业务数据；验证修复时应同时测试正常操作、恶意预设、拒绝路径与实际副作用。[1]
从模拟，到验证
找一个获准的环境，实际检查一次。
勾选用于本页自查，不会自动标记整课已学会。练习与清单刷新后重置。
本页已检查 0 / 5 项
文件处理接口需要安全调用系统工具，优先选什么？
能解释原因，再标记学会。
小测结果同步错题本；“已学会”沿用原有本地学习记录。
资料与依据
- OWASP · OS Command Injection Defense ↗
避免 OS 命令、参数分离与校验、参数注入及最小权限；规则依平台和工具而异
本页场景、人物与数据均为教学示例。互动选择不会上传；收藏、已学会与错题沿用当前浏览器本地存储。来源正文核对日期：2026-10-08。