CTFHub技能树的RCE模块，我前前后后刷了三遍，每次都有新收获。第一遍是冲着过题去的，第二遍开始琢磨绕过思路背后的原理，第三遍则是在整理自己写代码时的防御经验。RCE这个词在CTF圈子里出现频率极高，全称是Remote Code/Command Execution，翻译过来就是远程代码执行或者远程命令执行。很多刚入门的朋友一看到RCE题目就发怵，觉得要记一堆payload，其实真不是这样。你只要把命令拼接的逻辑、常见过滤的绕过思路、以及业务代码为什么会把用户输入拼进命令这三个问题想清楚，CTFHub技能树这套命令注入题基本就能顺畅过关，而且这套思路放到真实代码审计里也一样管用。
这篇文章我打算从最基础的原理讲起，然后按CTFHub技能树的出题思路，把无过滤、过滤关键字、过滤空格、前端JS验证这几种典型场景逐个拆解，最后再从防御端聊聊开发时怎么避免写出这种漏洞。内容适合正在刷CTFHub的入门选手，也适合搞Web开发想补充安全知识的朋友。所有演示都只在CTFHub、本地靶场这类授权环境中进行，这点务必注意。
1. RCE命令注入是个啥？先看一道最基础的CTF题
1.1 从CTFHub技能树的一道题目讲起
CTFHub技能树的Web方向里，RCE是一个独立章节，下面又细分了命令注入、代码执行等多个子分类。其中命令注入最典型的入门题，就是“无过滤命令注入”。题目通常长这样：一个输入框，让你提交目标IP地址，后台代码大概就是执行ping命令来检测主机是否在线。这种题的要求很简单——找到办法，让这台服务器执行你想要的系统命令。
我第一次做这道题的时候，第一反应是在输入框里填一个正常IP，比如127.0.0.1，然后加上一个分号，再接一个ls。结果还真就把当前目录列出来了。这个操作看起来简单，但背后涉及的恰恰是命令注入的核心逻辑：后台代码把用户输入原封不动地拼接到了系统命令里，没有做任何过滤和转义。分号在Linux Shell里是命令分隔符，前面ping命令正常执行之后，后面的ls同样会被当作新命令执行。
这种“无过滤”类型的题目价值很高。它把所有干扰项都去掉，只留最原始的命令注入形态，目的就是让你直观地感受漏洞是怎么产生的。很多人在这一步栽跟头，不是不会写payload，而是压根没意识到输入框里的内容会被拼进系统命令。所以我把这个基础形态放第一小节，后面所有花里胡哨的绕过，本质上都是在这个基础上叠加了各种过滤条件。
1.2 命令注入和代码执行的区别，为什么经常被放一起讨论
CTF题目里经常会看到RCE这个大帽子，下面再细分命令注入（Command Injection）和代码执行（Code Execution），进阶一点还会遇到Java的表达式注入（EL表达式、SpEL表达式）、PHP的模板注入（SSTI）等。命令注入和代码执行一字之差，但攻击结果和触发方式有明显差异。
命令注入，核心是把用户输入拼到操作系统命令里，最终执行的是Shell命令，比如ls、cat、id、whoami。武器库里主要是分号、竖线、与或符号这些Shell拼接符。而代码执行，则是把用户输入拼到了后端语言的代码层，比如PHP的eval函数可以直接把一段字符串当成PHP代码执行，最终跑的是PHP语句，像phpinfo()、system('id')这些。
但这两者经常混在一起讨论，因为在真实场景里它们的目标都一样——在目标服务器上执行任意命令，拿到权限或敏感信息。很多PHP函数本身就具有双重性质，比如system、exec、shell_exec既能作为命令执行的最终调用点，也常被恶意用户通过代码执行链去调起来。CTFHub技能树把这几个场景放在同一个RCE章节里，实际上是让你把“任意命令执行”的底层能力吃透，遇到代码执行时也能自然地往命令执行的方向去打通。判断一道题到底属于哪种类型，关键看触发点是命令拼接还是代码拼接，这在后文的实操例子中会有更直观的体会。
2. 命令注入的底层逻辑：为什么一串payload能执行系统命令
2.1 Shell拼接规则：分号、管道、与或这些符号到底干了什么
要理解命令注入，首先要熟悉Linux Shell的几个命令连接符。这不是什么高深的知识点，但在CTF题里经常用到，因为每个符号的语义不同，绕过场景也完全不同。
- 分号（;）：顺序执行多条命令，不管前面是成功还是失败，后面的命令都会执行。比如
127.0.0.1;whoami，先执行ping，再执行whoami，互相不影响。这是最常用的拼接方式。 - 管道符（|）：把前一个命令的输出作为后一个命令的输入。
127.0.0.1|whoami会先执行ping，然后把ping的输出交给whoami处理，最终显示的是whoami的结果。这个符号还有一个变种||，是逻辑或，意思是前一条命令失败才执行后一条；&&则是逻辑与，前一条命令成功才执行后一条。这些组合在绕过过滤时经常用到。 - 换行符（%0a）：本质上也相当于命令分隔符，URL编码后的换行符在HTTP请求中不会被过滤规则命中，因为过滤逻辑可能只匹配了明文符号。用Burp Suite构造请求时，
%0a这类编码经常能绕开后端的字符串匹配。 - 反引号
``和$()：命令替换。这两个符号可以执行被包裹的命令并把输出替换到原命令中。比如127.0.0.1whoami`` ，Shell会先执行whoami，再拼接到原命令里，最终执行的是127.0.0.1 root这样的命令。这类符号在过滤器只拦截关键字、不拦截符号时特别好用。
我在CTFHub上测试过，无过滤题目里直接用分号就能通，但遇到过滤规则时，管道符、换行符、命令替换常常能给你意外的效果。总之，理解这些符号的语义是第一个基本功，因为后续的payload设计本质上就是“在满足过滤规则的前提下，用Shell语法组合出合法的命令表达式”。
2.2 PHP里那些危险的RCE函数：system、exec、shell_exec、pcntl_exec
CTFHub技能树的RCE题目大部分基于PHP环境，因为PHP是CTF命题最常用的语言之一。PHP里能执行系统命令的函数非常多，这些函数既是漏洞成因，也是我们解题时的“出口”。
最常用的几个我在实践里统计过一个表：
| 函数名 | 特性 | 典型用法 |
|---|---|---|
system() | 执行外部命令，并输出结果 | system("whoami"); |
exec() | 执行外部命令，但只返回最后一行 | echo exec("ls -la"); |
shell_exec() | 执行命令并把完整输出作为字符串返回 | echo shell_exec("id"); |
`（反引号） | PHP中的命令执行运算符，等价shell_exec | $out = `ls`; |
passthru() | 执行外部命令并直接输出原始结果 | passthru("cat /flag"); |
popen() | 打开进程文件指针，可读可写 | popen("whoami", "r"); |
proc_open() | 更底层的进程控制函数 | 用法复杂，常用于绕过禁用函数 |
pcntl_exec() | 在进程空间执行指定程序，一般配合其他函数用 | pcntl_exec("/bin/sh", ["-c", $cmd]); |
其中pcntl_exec()在真实环境里常被用来绕过disable_functions。它的特点是会直接用新程序替代当前进程，不会产生新的Shell子流程，所以有些安全软件或函数禁用策略监视的是exec、system这类点，却漏掉了它。CTFHub技能树里专门设置了相关的题目，考察的就是“了解多少PHP命令执行函数”这个点。我第一次碰到pcntl_exec题目时，尝试用常规的?cmd=system('cat /flag');，结果被禁了。后来注意到环境说明里提示启用了pcntl扩展，改用pcntl_exec类的方式配合一个临时文件，才把命令打出来。这个过程的收获就是：做题不能只盯payload层面的过滤，还要关注后端到底有哪些函数可用、哪些被禁用。
2.3 一个payload的执行链路拆解
拿CTFHub无过滤题目来说，假设后端核心代码是：
<?php $target = $_REQUEST["ip"]; system("ping -c 3 " . $target); ?>当用户在输入框提交127.0.0.1;ls时，实际执行的就是：
ping -c 3 127.0.0.1;ls这里要补一个细节：很多人以为system只是把字符串交给操作系统执行，其实PHP的system函数内部会启动一个Shell（在Linux下一般是/bin/sh -c），然后由这个Shell去解析整条命令。正因为有这一层Shell解析，字符串里的分号、管道、通配符等特殊字符才会被解释执行，而不是被当成ping命令的普通参数。换句话说，命令注入的本质是“Web服务端的开发语言把不可信数据传给了Shell解释器”。
这也是为什么后端如果用的是exec且不经过Shell解析的命令数组，命令注入的难度会大幅提升。但Web开发中很少有人会写那么严谨的代码，多数人直接用字符串拼接，这就是漏洞频出的根源。理解这一条链路后，你就会明白：做题的本质不是找“神奇payload”，而是找“后端到底调用了哪个Shell解释器，以及用户数据在拼接后处于什么位置”。
3. CTFHub技能树实操：从无过滤到各种绕过
3.1 第一关：无过滤命令注入，直接把ls写进去
CTFHub的“命令注入-无过滤”这道题，是新手进入RCE世界的第一道门。题目页面通常只有一个输入框，显示“Ping”字样，让你输入IP地址。无过滤意味着空格、关键字、特殊符号都能直接用，所以我们只需要考虑payload能不能被系统执行。
我的通关步骤是：
- 先提交
127.0.0.1，观察回显。如果页面能显示ping结果，说明后端确实执行了ping命令。 - 提交
127.0.0.1;ls，看是否列出目录文件。 - 用
cat flag*或者cat flag_*之类的方式读取flag文件。
这里有个最容易卡壳的地方：flag文件的名字往往是未知的，比如flag_123456.php这种随机串。如果你直接cat flag大概率会提示文件不存在。解决方法很简单，先用ls看看目录里到底有什么，再根据实际文件名去cat。这是最笨但最有效的方法，没有任何技巧成分，就是“先侦察，后拿结果”。
无过滤这道题的意义还在于，它能让你体会到一个真实的Web应用全流程：前端输入框、HTTP请求、PHP接收参数、命令拼接、Shell执行、结果回显。很多人在这一关用的是别人给的payload，虽然过了题，却不知道每一步发生了什么。我建议你在浏览器开发者工具里看看请求参数，在Burp Suite里重放几次，改改参数名，观察一下响应变化。把这一套流程走顺了，后面的题目才不至于靠猜。
3.2 过滤flag关键字：编码、拼接、通配符三件套
过了无过滤这关，下一题常见的是“过滤flag关键字”。也就是后台检测到你输入的内容里包含flag这个子串，就拒绝执行。如果直接cat flag，系统会拦截。但Shell语法本身给了我们很多变通手段。
第一种思路是通配符。Linux的路径通配符*、?、[ ]都能帮我们绕过关键字匹配。比如cat flag*或者cat f*。当过滤规则只是简单判断字符串里有没有flag这两个连续字符时，fla*显然能绕过，因为提交的字符串里根本没有完整出现flag。
第二种思路是Shell变量拼接。先声明一个变量或利用环境变量来组合出字符串。比如：
a=f;b=lag;cat $a$b或者利用两个已有的环境变量拼接，但这种方式在CTF里更常用于绕过“字符串包含检测”。简单说，过滤规则匹配的是你提交的整条payload，而Shell在执行时才把变量解算成真实命令，所以静态的字符串匹配规则拿它没办法。
第三种思路是编码。比较经典的是Base64编码配合管道命令：
echo 'cat flag' | base64 echo 'Y2F0IGZsYWc=' | base64 -d | bash第一步先在本地得到cat flag的Base64串，第二步把这个串放进payload，服务器执行时会先解码再交给bash执行。这样提交的payload里不但没有flag，连cat都没出现，只是过滤规则如果没有拦base64和echo，这类方法就有效。我在做题时发现，CTFHub有些题目对“短字符串”过滤比较宽容，Base64方式几乎百试百灵。
3.3 过滤空格：$IFS家族的替代方案
命令注入里另一个高频过滤项是空格。很多题目会检测你的输入里有没有空格字符，有就拒绝。但Shell不会因为空格被过滤就无解，因为Tab、换行、变量替换都可以充当参数分隔符。
这里最经典的工具是$IFS变量。IFS是Shell里的内部字段分隔符（Internal Field Separator），默认包含空格、Tab、换行。你可以用它来替掉空格。比如：
cat$IFS/etc/passwd注意这里不能带空格，cat和$IFS之间是紧挨着的，Shell在展开$IFS后才会把它当作分隔符。还有一种更保险的写法是用花括号包裹：
${IFS}cat${IFS}/etc/passwd不过这个写法不一定在所有Shell下都生效，因为${IFS}展开后是个变量值，变量直接和命令拼接时有些Shell会解析成“命令名的一部分”。我在CTFHub实操时，更常用的替代是$IFS$1或者${IFS}配合重定向。比如读flag文件时直接写：
cat${IFS}flag*在多个靶场环境里测试，这条命中率最高。
除了$IFS，Tab字符（%09URL编码）也能替代空格。有些过滤规则只匹配空格，但如果同时过滤了Tab，那再用Tab就失效了。要灵活一点，把$IFS、$IFS$9、{cat,flag}这种花括号展开、重定向符<当成备选方案的组合拳。我自己的习惯是建一个payload速查表记载这些替换方案，刷题时一个个试，而不是现场硬想。
3.4 前端JS验证：绕过之前先分清是前端卡你还是后端卡你
CTFHub技能树里有一部分RCE题目会有“前端JS验证”这个标签，指的是页面嵌入了JavaScript代码，在浏览器端就拦截了某些关键字或符号。这种题目对小白来说特别喜欢卡人，因为你在输入框里敲cat /flag，还没到服务器就被浏览器弹窗或者提示拦住，很多人就此以为后端也过滤得死死的。
遇到JS验证，第一步永远是绕过前端，而不是去猜后端的过滤规则。最简单的办法是直接用Burp Suite抓包改包，绕过浏览器直接给服务器发HTTP请求。或者用浏览器开发者工具把JS逻辑禁掉，再重新提交表单。因为前端验证只影响浏览器端的交互体验，不影响服务器端是否接收参数。
但这里有个关键点：前端JS验证题目里，后端不一定没有过滤。CTFHub的题目命名带“JS前端验证”，说明出题人故意只加了前端限制，后端很可能是直接执行命令的。但你自己要养成习惯：把前端绕过之后，再测一遍基本的;ls，确认后端到底过滤了什么。我在刷题时遇到过表面写了“JS前端验证”的题，后端居然额外拦掉了flag和空格，不测根本不知道，最后绕了两层才过。所以正确顺序是：先绕过前端，然后按常规命令注入逐层探测，不要因为题目只提“前端验证”就轻视后端策略。
4. 实战中积累的绕过技巧与排查思路
4.1 绕过技巧速查表：粘贴到笔记里随时翻
刷完CTFHub的RCE技能树后，我把常用的绕过技巧整理成了一张速查表。以下内容可以复制到自己的笔记里，做题时对照使用。
| 被过滤的内容 | 替代思路 | 示例payload |
|---|---|---|
| 空格 | IFS变量、Tab、重定向符 | cat${IFS}flag |
flag关键字 | 通配符、变量拼接、编码 | cat fla?、cat f*、`echo Y2F0IGZsYWc= |
cat等命令关键字 | 反斜杠转义、变量拼接 | c\at flag、c""at flag |
/路径分隔符 | ${PATH:0:1}、cd进目录 | cd ..;cat flag |
| 管道符和分号 | 换行符%0a、逻辑与或、命令替换 | 127.0.0.1%0als |
| 反引号被过滤 | $()命令替换 | $(cat /flag) |
| 数字被过滤 | 极少见，可用通配符匹配文件名 | cat fl* |
bash被过滤 | sh、dash、/bin/sh | 直接用sh -c |
| IP参数本身校验 | 看后端是否校验IP格式，有些可以穿参数绕过 | 尝试?ip=127.0.0.1;ls或?ip[0]=... |
这个表越往后做越完善。我后来在GitHub上也看到一些开源payload字典，但总觉得它们太多太杂，反而不如自己在做题过程中按题目类型整理的实用。因为每个CTF平台的出题风格不同，过滤点也不同，自己整理的速查表往往最能对应自己的知识盲区。
4.2 在线靶场踩坑实录：常见报错和排查方法
在线靶场刷题和本地自己搭环境不一样，有很多坑。我在CTFHub上遇到的几类典型问题，值得单独拿出来说说。
第一类：提交后没反应/不显示结果。出现这种情况，先检查payload是不是根本没执行成功。比如某些环境禁用了system、exec，或者后端代码用了shell_exec但不打印结果。排查方法很简单：分别测试;echo 1、;ls、;whoami，看哪一步有回显。如果只回显了 “1” 而没有命令输出，很可能结果是赋值给变量后没有输出逻辑，或者是命令执行成功但输出被吞了。这时候可以考虑用;ls > 1.txt把结果写到文件里，再用另一个接口读取。
第二类：在线平台对并发和请求频率有限制。有的靶场反向代理会拦截短时间内的大量请求。我一开始写脚本批量跑payload时，经常整段被WAF拦截，页面直接返回403。这种时候不要硬刚，把脚本延时调大，每次请求之间间隔1到2秒，或者改用手工测试，效率反而更高。
第三类：payload里的特殊字符被在线编辑器转义。有些平台的前端页面会在提交时把#、%这类字符自动做URL编码，导致你看到的payload和实际发出去的payload不一样。解决方法是用Burp Suite看真实请求，亲自改HTTP报文，而不是依赖页面输入框。
第四类：CTFHub的题目环境有时会过期或者数据被重置。如果你做一道题做到一半发现flag内容变了，甚至ip变了，可能是环境被重置了。这种情况只需要重新获取环境信息，把IP、端口刷新一下，重新提交即可。
4.3 怎么系统化积累payload而不只是背题
很多人在网上找一份“命令注入payload大全”，背来背去，一到新题目面前依然抓瞎。原因是payload只是结果，没有形成“为什么这么写”的思维链路。我自己的经验是，把每次成功绕过的题目拆成三个要素存进笔记：
- 过滤规则是什么（拦了哪个字符、哪个命令、哪种编码）
- 绕过原理是什么（利用了Shell的什么特性）
- payload中最关键的那个符号或语法是哪一块
比如我记录“用花括号+IFS绕过空格”时，会备注：“原理是Shell变量展开发生在词法解析之后，做静态字符串匹配的WAF往往只检查原始文本，没检查展开后的执行结果。记住这个点，比记住${IFS}更重要。” 这样积累几个月后，你看新题目的方式会从“这个payload我没见过”变成“这个过滤点可以用Shell展开绕，或者用编码绕，或者用命令替换绕”。这种能力不是背面试题能得来的，必须通过大量实践去沉淀。
5. 从攻到防：开发人员怎么避免自己的代码变成RCE入口
5.1 编码层防御：白名单、转义、禁用危险函数
刷CTF题和真实开发是一体两面。我做过几年PHP后端开发，在真实项目中见过不少同事写出和CTF题几乎一模一样的代码。比如拼接ping命令检测存活、拼接shell脚本备份数据库、拼接ffmpeg命令处理视频，这些场景一旦用户可控参数被拼进去，就是妥妥的命令注入。
先说最简单有效的三层防御思路。
第一层：白名单校验。如果业务上只需要IP，那就严格校验IP地址格式，不合法直接拒绝。PHP可以用filter_var($input, FILTER_VALIDATE_IP)，Java可以用InetAddress.getByName()再验证，Python可以用ipaddress.ip_address()。白名单的好处是从根上杜绝了特殊符号进入命令的可能性，因为连合法格式都不满足。
第二层：参数化调用，避免字符串拼接进入Shell。PHP里如果必须执行外部命令，优先用带参数数组的形式：
exec("/bin/ping", $output);在PHP 7.4以上，还可以考虑用shell_exec配合escapeshellarg做转义。escapeshellarg会给参数加单引号并转义内部单引号，这样用户输入即便包含分号，也只会被当成一个普通参数字符串，不会被Shell解释成命令分隔符。但注意这个方法有它自己的边界，比如传入的参数本身需要特殊处理时，它不一定满足所有场景，所以白名单才是最稳的。
第三层：禁用危险函数。生产环境里如果实在用不到PHP的系统命令执行函数，在php.ini里把system、exec、shell_exec、passthru、popen、proc_open加入disable_functions。这也是很多安全加固方案的常规操作，成本低、见效快，缺点是要提前和运维确认哪些业务真的需要这些函数。
以上三层是经典的“本质安全”，比单独装一个WAF或者写一堆过滤正则要可靠得多。因为过滤正则永远存在绕过空间，CTFHub的那些绕过技巧说明了一切。
5.2 代码审计视角：如何快速定位命令注入点
最后聊聊审计视角。不管你是甲方安全工程师、乙方渗透测试人员，还是自己写代码想复盘，命令注入点的定位基本有固定套路。
第一是全局搜索危险函数。PHP项目搜system(、exec(、shell_exec(、passthru(、popen(、proc_open(、pcntl_exec(。把这些点全部列出来，然后逐一判断参数是否由外部输入控制。很多自动化的代码扫描工具也能做这件事，但我一直觉得人工确认不能省，因为误报率很高。
第二是追踪输入来源。搜到危险函数后，往前看变量的传递链路。是$_GET、$_POST、$_REQUEST直接取值，还是经过了某层封装后又拼接到命令字符串里？有没有经过过滤函数？过滤函数能不能被绕过？审计时把这条链路画清楚，漏洞基本就浮出水面了。
第三是测试命令拼接形态。看到system("ping -c 3 " . $target)这种形式，第一时间应该意识到注入点就在$target。如果业务层不能改成白名单校验，至少要用escapeshellarg包一层再拼。如果看到shell_exec("tar -czf " . $backup . " " . $folder . "")这种，还需要防范目录遍历和命令注入两个维度的问题。
我在Code Review时经常跟开发同事说一句话：不要相信用户输入，尤其是当它要进入操作系统命令的时候。所有用户可控参数都要默认当成恶意输入来处理，即使当前业务场景看起来人畜无害。因为攻击者永远比你更了解你的代码里那些“边界”。
做安全这件事，攻防知识从来不是对立的。你在CTFHub上刷过的每一次绕过，最终都可能变成你在真实系统上修补的一个漏洞。我希望这篇关于命令注入的文章，能帮你在解题之外建立起更完整的知识框架。下一次遇到RCE题目，先别急着找payload，试着想想它过滤了什么、为什么能绕过、如果换成你写这段代码会怎么防——这三步走顺了，RCE这道坎就算真正跨过去了。
