2.1 三条线索#

2.2 本关和「空字符/通配符」那关的本质区别#

那关参数 cmd 的值就是一条完整命令，不存在拼接；本关是拼接型：

1
ping -c 1 $ip
2
         ^^^^  把这里换成  <地址><运算符><命令>

所以本关唯一要解决的就是一个问题：用哪个运算符，把第二条命令接在 ping 后面。

2.3 拼接后 Shell 实际看到什么#

以 ?ip=127.0.0.1%3Bcat%20/flag 为例（分号写成了 %3B，这一点见 3.3，不编码会直接失败），PHP 解码后拿到 127.0.0.1;cat /flag，拼完交给 shell 的字符串是：

1
ping -c 1 127.0.0.1;cat /flag

shell 按 ; 切成两条独立命令，依次执行，两条的输出都进 stdout，system() 原样吐回给你。于是 ping 的结果和 cat /flag 的结果会上下挨在一起回显 —— 这是判断”注入成功了没有”的最直观依据。

2.4 关键实测：本靶机的 ping 必然失败#

这一点不实测很容易被”课本知识”带偏。实际探测结果如下。

原因：busybox 的 ping 需要 CAP_NET_RAW（一般靠 root 或 setuid 获得），而 PHP 以 www-data 身份运行，拿不到该权限 —— 它只是打印了一行 PING ... 56 data bytes 就报错退出，一个 ICMP 包都没发出去。

这一条直接决定两种”有条件运算符”的生死：

2.5 四种运算符的取舍（含实测）#

如果非要让 && 生效，得先自己制造一个成功命令，例如 ?ip=x%3Btrue%26%26cat%20/flag。既然已经有 ; 可用了，这就属于多此一举 —— 这正是本关的”题眼”所在。

结论：本关实际可用的是 ;、\|\|、&，&& 因为靶机 ping 无权执行而天然失效。

3.1 打开内置浏览器#

新版 UI 顶部标签是 Dashboard / Target / Proxy / Intruder / Repeater，scope 不在 Target 里（在 Settings → Tools → Scope）。内置浏览器入口：

Proxy → Intercept 页 → 右上角 Open browser

免配代理、免装证书，直接用。

3.2 三步走到 Repeater#

也可以跳过浏览器：直接在 Repeater 里手写 GET /?ip=... HTTP/1.1 + Host: <靶机>，效果一样。

3.3 改 payload 的两个坑#

坑一（最容易踩）：; 和 & 都会在 HTTP 层被吃掉。

这台服务器的 PHP 把 ; 也当作参数分隔符（arg_separator.input 里含 ;，这是 PHP 5 时代的默认值），所以分号和与号一样，裸写就会被切开。

实测对照：

这就是”BP 里明明发了 payload 却什么都没有”的头号原因 —— 响应 200、PING 那行也在，看起来一切正常，实际第二条命令从来没进过 PHP。

必背编码表：

铁律：在 Repeater 的 URL 栏里，;、&、空格一律百分号编码。照 shell 的写法直接敲，payload 会死在 HTTP 层，而且不会有任何报错。

坑二：别忘了 %20。

?ip=127.0.0.1%3Bcat /flag 中间那个裸空格，稳妥写法是 %20：

1
?ip=127.0.0.1%3Bcat%20/flag

3.4 逐个验证#

按 Ctrl+R（或点 Send）依次重放，观察 Response：

1
GET /?ip=127.0.0.1%3Bcat%20/flag        ← 首推，无条件执行
2
GET /?ip=x%7C%7Ccat%20/flag             ← ping 必失败 ⇒ 必然触发
3
GET /?ip=127.0.0.1%26cat%20/flag        ← 后台运行
4
GET /?ip=127.0.0.1%26%26cat%20/flag     ← 会哑火，用来验证 2.4 的结论

四条严格按 3.3 的规则编码：;→%3B、&→%26、空格→%20、|→%7C。

前三条能出 flag，最后一条空白 —— 这个”反差”就是本关最值得记住的地方。

6.1 案发现场#

在 Burp Repeater 里按”shell 的写法”直接敲：

1
GET /?ip=127.0.0.1;cat%20/flag HTTP/1.1
2
Host: 80-3746d733-....challenge.ctfplus.cn

响应是 200 OK：

1
PING 127.0.0.1 (127.0.0.1): 56 data bytes
2
<code><span style="color: #000000"><?php ...源码...</span></code>

没有 flag，也没有任何报错。 最迷惑人的是 PING 那一行照常打印，看起来”命令执行一切正常”，很容易让人误判成”payload 写错了”而反复换 payload。

6.2 根因：你的 payload 要穿过三层#

坑就在第 ② 层：切分发生在解码之前。 所以”你以为的一个参数”，在 PHP 眼里可能是两个。

6.3 逐步拆解#

裸分号：?ip=127.0.0.1;cat%20/flag

编码分号：?ip=127.0.0.1%3Bcat%20/flag

一句话：%3B 让分号”伪装”成普通字符混过切分阶段，解码后才现出原形，正好赶上第 ③ 层。

实测对照（打在人把子上）：

6.4 同类字符全表#

A 类 —— 会在第 ② 层被改写（必须编码）

B 类 —— 会在第 ① 层就被截断

# 是 URL 的 fragment 分隔符，属于客户端行为。用 curl / 浏览器时一定要 %23；Burp 的 URL 栏大多会保留，但别赌。

C 类 —— 第 ② 层安全，但第 ③ 层（shell）会搞事

这类不需要为了过 HTTP 层而编码，但它们才是命令注入的”武器库”：

6.5 排查手法：人质标记法#

“发了 payload 却没有回显”时，不要急着换 payload，先定位它卡在哪一层。做法是往 payload 里塞一个独一无二的标记当”人质”：

1
?ip=1.1.1.1;echo HOSTAGE_A        ← 裸写
2
?ip=1.1.1.1%3Becho HOSTAGE_A      ← 编码

然后看回显：

这个手法在本题之外同样通用：先证明”我能执行一条无害命令”，再换成真 payload。

6.6 回头再看题面：页面教的 vs 编码补的#

这一节把整道题的两半合起来看。

靶机注释教的 SHELL 运算符语义，属于 shell 层（第 ③ 层）；而 %3B 这类编码属于 HTTP + PHP 层（第 ② 层）。

没有第 ② 层的知识，第 ③ 层的知识一次都用不上 —— 你完全理解了四种运算符的行为，但只要 ; 裸着写，shell 那一层永远收不到它。

页面给的四个例子，全都是命令行里的写法，落进 URL 都得重新翻译一遍：

为什么这一块特别容易被忽略：

1. 页面里没有一个例子是 URL 写法，清一色命令行写法；
2. 页面唯一的 GET 示范 ?ip=8.8.8.8 不含任何分隔符 —— 照抄它永远成功。

于是形成一个陷阱：照抄示范能过；一旦你按页面的知识补上一个 ;，就踏进了页面没写的那一半。

两者是互补关系，缺一不可：

打个比方：页面教你”这把钥匙能开哪扇门”，编码保证”钥匙能插进锁孔”。 知识点是页面给的，实操是页面留白的 —— 而留白的那部分，才是这道题真正想让你踩一次坑的地方。

6.7 一句话记住#

URL 里遇到 ; & + % # 和空格，一律百分号编码。 其中 ; & 改变的是参数个数（最危险，静默失败），+ % 改变的是内容，# 会让整段消失。