关于实战的思考-从皮卡丘靶场文件包含出发

前言：

​ 做到文件包含这个关卡，一直在想文件包含实战怎么利用的问题，这个也给了我一点启发，等靶场过完之后我全部关卡都想一下实战怎么用的问题，我觉得这才是皮卡丘靶场的真正作用。而且，我发现皮卡丘的源码里这么多的小彩蛋，显然是开发者当时特意写的，但实际上我在翻阅网上的通关教程的时候，根本没看见过有人扒了源码对照题目做。遗憾之。。。。而且，我越来越意识到，实战和ctf关卡是两回事，谁家的漏洞会照着ctf一模一样出现，一模一样套路呢？不会的。有个佬一直在跟我说，ctf只是游戏。【当然确实是能练习提高能力的游戏，脑洞题除外hhh】而且，目前已经看到很多自动化渗透的agent工具了，大量的低端漏洞已经贬值了。【插一句，我有点想自己以后搓agent跑这个嘻嘻】

​ ok，言归正传，以下是我提问之后ai给出的回答，在这里存档一下，说不定等我去src平台玩几圈回来之后会有新的体会【嘻嘻，菜鸟也有梦想】

第一步：怎么发现文件包含漏洞？

看 URL 特征。 在测试目标网站时，关注 URL 里出现这些参数的地方：

可疑参数名 常见值形态 ?page=xxx page=about.php ?file=xxx file=header.html ?path=xxx path=/images/logo.png ?template=xxx template=default.php ?lang=xxx lang=en.php ?module=xxx module=user.php

测试手法（用 Burp Suite）：

  1. 正常访问，观察页面正常返回内容

  2. 把参数值改成 ../../../etc/passwd ，看返回内容是否变成了系统文件内容

  3. 把参数值改成不存在的文件（如 asdfghjkl.php ），看报错信息里是否暴露出文件路径

  4. 改成 php://filter/… 尝试读源码（base64 返回）【伪协议很多，这里只是举例。】

  5. 截断测试：加 %00 （空字节截断，老 PHP 版本有效）、加 ? 或 # （绕过后缀拼接）

Burp Suite 中实操： 抓到含有可疑参数的请求 → 右键发到 Repeater → 逐个测试上述 Payload → 看 Response 是否异常。

image-20260812012655260

实战决策树：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
发现 ?file= 或 ?page= 参数
              │
              ▼
   ① 试 ../../../etc/passwd
              │
      ┌───────┴───────┐
      ▼               ▼
   有内容返回       没反应 / 报错
      │               │
   ✅ 漏洞存在        │
      │        ② 试 php://filter 读源码
      ▼               │
  继续利用      ┌─────┴─────┐
               ▼           ▼
           有 base64    还是不行
               │           │
          ✅ 能读源码   ③ 看文件上传功能
               │           │
          ┌────┴────┐      ▼
          │         │   能上传图片/zip？
    读 config.php 看    │
     数据库密码    ┌───┴───┐
                  ▼       ▼
              能用 zip  能用 phar
                  │       │
             试 zip://  试 phar://
                  │       │
                  ▼       ▼
              包含压缩   触发反序列化
              包内 shell  拿 Shell

分场景讲解什么情况用哪个协议

场景 1：只验证了漏洞存在，停留在”能读文件”（最常见，占 80%）

用 php://filter 读源码收尾。

读完数据库密码 → 连数据库 → 剩下的路你自己走。 大多数 SRC 报告写到这一步就够了，因为危害已经足够证明。

场景 2：allow_url_include=On，但服务器不能访问外网

用 data:// ——不需要外部服务器，自己写代码自己执行。

这串 base64 解码后是

1
<?php phpinfo();?>

。 data:// 的意思是”后面的数据本身就是内容，不需要去某个 URL 取”。等于你把代码直接写在 URL 里了。

更进一步——用 data:// 写一句话：

解码后是 

1
<?php @eval($_POST['cmd']);?>

。蚁剑直接连原页面。

场景 3：有文件上传功能，但只允许上传图片

用 zip:// ——把一句话木马藏在 zip 压缩包里，然后用文件包含去包含它。

步骤：

  1. 把 shell.php （一句话木马）打成 shell.zip
  2. 把 shell.zip 改名为 shell.jpg 上传
  3. 用文件包含去访问：
    %23 是 # 的 URL 编码， # 在 zip 协议里的意思是”打开这个压缩包，取里面叫 shell.php 的文件并执行”。服务器拿到的 shell.jpg 看起来是图片，但 zip:// 协议会把它当压缩包打开，取出里面的 PHP 文件执行。

这是实战中最值钱的组合拳——文件上传 + 文件包含 = 绕过一切上传过滤。

场景 4：allow_url_include=On + WAF 拦截了 data://

用 php://input ——POST Body 里塞 PHP 代码。

URL：

1
php://input

在 Burp Suite 里，POST Body 写上：

1
<?php phpinfo();?>

php://input 会读取 POST Body 里的原始内容，当成 PHP 执行。有些 WAF 会过滤 URL 里的 data:// 但放过 php://input 。

image-20260812013230715

一句话总结

php://filter 是瑞士军刀——啥条件下都能用，读源码永远是最高优先级的利用方式。其他协议是”特定条件下的特种武器”——条件不满足就是用不了，不是你没试够。实战中最常见的情况：用 ../etc/passwd 验证漏洞 → 用 php://filter 读源码拿密码 → 写入 SRC 报告。就够了。