1. 项目概述：从“伪协议”到安全漏洞的深度透视
在Web安全领域，PHP伪协议（PHP Wrappers）是一个既强大又危险的存在。它原本是PHP为开发者提供的一套便捷的文件和流处理机制，允许开发者像操作本地文件一样，通过特定的协议前缀（如file://、http://、php://）来访问各种数据源。然而，当这套机制与不安全的用户输入相结合时，便会瞬间化身为攻击者手中的利器，轻松实现远程命令执行（RCE）和任意文件读取（LFI/RFI）等高危漏洞。今天，我们就从一个资深安全研究员的视角，彻底拆解这个经典且历久弥新的攻击向量。
简单来说，这个“项目”的核心就是剖析攻击者如何滥用PHP内置的伪协议处理器，绕过常规的安全防护，直接与服务器操作系统或文件系统进行危险交互。它绝不是一个鼓励攻击的“教程”，而是一份深入理解其原理、机制、利用条件及防御策略的“解剖报告”。对于Web开发者、安全工程师乃至运维人员而言，透彻理解伪协议的运作方式和潜在风险，是构建健壮应用防线、进行有效代码审计和安全测试的必修课。接下来，我们将抛开晦涩的理论，直接切入实战场景，看看这些协议是如何被“玩坏”的，以及我们该如何应对。
2. 核心原理与协议家族深度解析
要理解攻击，必须先理解工具本身。PHP伪协议并非单一功能，而是一个家族。每个家族成员都有其特定的语法、能力和使用场景。攻击的成败，很大程度上取决于对目标环境所支持协议及其限制条件的精准把握。
2.1 协议处理器的工作机制
在PHP中，当使用如fopen()、file_get_contents()、include()、require()等文件系统函数时，如果传入的路径参数以某个协议前缀开头（例如php://input），PHP并不会直接将其当作普通文件路径处理。相反，它会将这个字符串传递给对应的“流包装器”（Stream Wrapper）进行处理。这个包装器是一个实现了特定接口的类，它负责解析协议后的内容，并将其转换为PHP可以理解的流数据。
关键在于，许多这类函数在接收用户可控的输入（如GET/POST参数、Cookie、HTTP头）时，如果未经过严格的过滤和验证，攻击者就可以精心构造一个包含恶意协议前缀的字符串，从而“劫持”程序的执行流，让本应处理普通文件名的代码，去执行攻击者指定的协议操作。
2.2 高危协议成员详解
并非所有伪协议都同样危险。我们将焦点集中在最常被用于攻击的几个核心成员上。
1.php://input- 原始POST数据读取器这是实现命令执行最经典的入口之一。php://input允许读取原始的POST数据。当allow_url_include配置为On时（这是一个非常危险且默认通常为Off的配置），结合include()或require()函数，攻击者可以直接将POST数据中的PHP代码传递给服务器执行。
- 攻击场景：假设存在一个漏洞点
include($_GET[‘file’]);，攻击者传入?file=php://input，并在POST Body中写入 ``，服务器便会执行phpinfo()。 - 核心限制：
allow_url_include=On是前提。此外，enctype=”multipart/form-data”时php://input无效。
2.php://filter- 数据流转换大师这是任意文件读取的“神器”，也是信息泄露和辅助攻击的利器。它本身不执行代码，但可以对资源流进行各种过滤（如编码转换）。
- 经典利用：读取PHP文件源码。由于服务器通常会直接执行
.php文件，我们无法直接通过Web访问看到其源代码。但php://filter可以将其内容进行Base64编码后输出。例如：?file=php://filter/convert.base64-encode/resource=index.php。服务器会读取index.php的内容，进行Base64编码，然后输出编码后的字符串，攻击者解码即可获得源码。 - 高级利用：结合编码构造“死亡字符串”，用于绕过某些WAF或触发其他漏洞。例如，使用多重过滤器嵌套。
- 核心价值：它绕过了“文件必须可执行才能查看内容”的限制，是源码审计和信息收集的突破口。
3.data://- 内联数据协议它允许在URI中直接嵌入数据。当allow_url_include=On时，它可以直接执行内嵌的PHP代码。
- 攻击示例：
?file=data://text/plain,<?php phpinfo();?>或更隐蔽的?file=data://text/plain;base64,PD9waHAgcGhwaW5mbygpOz8+（Base64编码版）。 - 特点：比
php://input更直接，无需额外的POST请求，一个GET参数即可完成攻击。
4.file://- 本地文件系统协议虽然看起来人畜无害，但在LFI（本地文件包含）漏洞中，它是遍历目录、读取系统敏感文件（如/etc/passwd、/proc/self/environ）的标配。
- 攻击示例：
?file=file:///etc/passwd。 - 注意：它受PHP的
open_basedir限制，但在该限制范围内仍可造成信息泄露。
5.zip://、phar://- 压缩包协议这两个协议可用于触发反序列化漏洞或进行文件包含。phar://尤其危险，因为PHAR（PHP归档文件）的元数据（stub和manifest）会被自动反序列化，如果其中包含恶意序列化数据，就可能直接导致代码执行，且通常不需要allow_url_include开启。
- 攻击模式：将恶意代码写入一个文件，打包成ZIP或PHAR，然后通过
zip://archive.zip#file.txt或phar://archive.phar/file.txt的方式去包含，有时能绕过对常规文件后缀的检查。
重要心得：在实际渗透测试中，第一步永远是信息收集。通过一个简单的LFI点，尝试
?file=php://filter/resource=/etc/passwd，不仅能确认漏洞存在，还能通过/proc/self/environ获取环境变量（可能包含数据库密码），通过/proc/self/fd/[id]读取临时文件，为后续攻击铺平道路。php://filter的编码功能在绕过某些简单的字符串过滤时也常有奇效。
3. 攻击链构建与实战场景复现
理解了单个协议的原理，我们来看看攻击者是如何将它们串联起来，形成完整攻击链的。这里我们模拟一个存在文件包含漏洞的简单应用场景。
假设有一个vuln.php文件，代码如下：
<?php $page = $_GET[‘p’] ?? ‘home.php’; include(‘pages/’ . $page); ?>这是一个非常典型的、未经过滤的文件包含漏洞。攻击者的目标是最终在服务器上执行任意命令。
3.1 第一步：漏洞探测与信息收集
攻击者不会一上来就尝试RCE。他们会先进行“无害”探测：
- 基础LFI测试：
/vuln.php?p=../../../../etc/passwd。如果成功读取，则确认存在目录遍历和文件包含。 - 伪协议支持测试：尝试
?p=php://filter/resource=vuln.php。如果返回了Base64编码的源码，则证明php://filter可用，并且能读到当前目录下的文件。这一步至关重要，因为它可能泄露数据库配置、其他包含点、关键逻辑等。 - 环境探测：尝试读取
?p=php://filter/resource=/proc/self/environ。如果服务器是CGI/FastCGI模式，这里可能包含USER、PATH、甚至HTTP_*头（如HTTP_USER_AGENT），攻击者可以尝试通过User-Agent注入代码。 - 配置信息推断：通过能否成功利用
data://或php://input，可以间接推断allow_url_include的配置状态。
3.2 第二步：利用php://input尝试直接代码执行
如果探测到allow_url_include可能为On，攻击者会直接尝试RCE。
- 发送一个GET请求：
GET /vuln.php?p=php://input - 在POST Body中写入：
<?php system(‘id’); ?> - 观察响应。如果返回了
uid、gid等信息，说明攻击成功，服务器以Web服务进程的身份执行了id命令。
实操要点：
- 使用Burp Suite或类似的代理工具可以方便地构造这种请求。
- 初始命令通常会使用
whoami、id、pwd来确认权限和位置。 - 如果直接执行失败，可能意味着配置不支持，或者存在额外的过滤（如过滤了
<?php标签）。此时需要尝试短标签<?=或利用php://filter进行编码转换绕过。
3.3 第三步：利用php://filter与文件日志实现组合攻击
这是更常见、也更高级的场景。假设allow_url_include=Off，直接执行被禁止。但我们可以利用服务器自身的日志文件作为“跳板”。
攻击思路：将PHP代码写入一个服务器必定会读取和记录的文件中，然后通过文件包含漏洞去包含这个日志文件，让其中的代码被执行。最常见的靶子是Web访问日志（如Apache的access.log）和SSH认证日志（auth.log）。
具体步骤：
- 确定日志路径：通过之前的LFI，可能已经读到了
/etc/apache2/apache2.conf或/etc/nginx/nginx.conf，从而确定日志路径（如/var/log/apache2/access.log）。或者使用常见的默认路径进行爆破。 - 污染日志：向Web服务器发送一个包含PHP代码的HTTP请求。例如，在User-Agent中注入代码：
User-Agent: <?php system($_GET[‘cmd’]); ?>。这个请求会被完整记录到access.log中。 - 包含日志文件：利用文件包含漏洞，去包含这个已经被污染的日志文件：
/vuln.php?p=/var/log/apache2/access.log。此时，日志文件中的文本会被当作PHP代码解析。 - 执行命令：由于日志文件中的代码已经包含了
system($_GET[‘cmd’]);，攻击者现在可以通过&cmd=id来传递命令参数，最终实现RCE。
避坑指南：
- 日志文件权限：Web进程（如www-data用户）必须有读取日志文件的权限。
- 日志内容干扰：日志文件中存在大量其他字符（IP、时间戳等），可能会破坏PHP语法导致解析失败。因此注入的代码需要足够健壮，通常使用
?><?php ... ?>来闭合前面可能存在的意外字符。 - 文件大小：过大的日志文件可能导致包含超时或内存耗尽。攻击者可能会先发送一个导致404的错误请求，使日志条目独立且易于定位。
3.4 第四步：利用phar://触发反序列化
如果目标系统安装了phar扩展（默认常安装），且存在文件包含点，即使allow_url_include=Off，也可能通过phar://触发反序列化漏洞。
- 攻击者编写一个包含恶意
__destruct()或__wakeup()魔术方法的类，并生成一个PHAR包。 - 将这个PHAR包上传到服务器（可能通过其他漏洞点，如图片上传）。
- 利用文件包含漏洞，包含这个PHAR包中的某个文件，例如：
?p=phar:///path/to/uploaded/evil.jpg/内部文件。在解析PHAR元数据时，恶意类的反序列化过程被触发，导致代码执行。
这个攻击链的关键在于找到一个上传点，并且上传的文件内容不会被破坏（如图片二次渲染）。
实战经验：在真实环境中，直接利用
php://input或data://一击即中的情况越来越少，因为allow_url_include=On是不安全的配置，稍有经验的管理员都会关闭它。因此，组合利用能力至关重要。通过php://filter读源码找其他漏洞（如上传点、反序列化点），通过日志污染、通过phar反序列化，这些才是更常见的攻击路径。攻击者的耐心和迂回能力，往往决定了漏洞利用的成败。
4. 防御体系构建：从开发到运维的全链路防护
理解了攻击，防御就有了清晰的靶子。防御伪协议攻击不是一个单点动作，而是一个从代码编写、框架选择、服务器配置到安全监控的体系化工程。
4.1 代码层：白名单与严格过滤
这是最根本、最有效的一环。
- 绝对禁止用户输入直接控制文件路径：这是万恶之源。如果业务必须动态包含，请使用白名单机制。
$allowed_pages = [‘home’ => ‘home.php’, ‘about’ => ‘about.php’, ‘contact’ => ‘contact.php’]; $page_key = $_GET[‘p’] ?? ‘home’; if (!array_key_exists($page_key, $allowed_pages)) { die(‘Invalid page requested.’); } include(‘pages/’ . $allowed_pages[$page_key]); - 如果需要处理动态路径，进行严格净化：使用
basename()函数去除路径中的目录部分，防止目录遍历。但注意basename()在非ASCII字符下可能有问题，且无法防御伪协议（因为php://没有斜杠）。因此，必须检查字符串开头。$file = $_GET[‘file’]; // 禁止任何协议流 if (preg_match(‘/^(php|file|glob|data|http|zip|phar|zlib|ftp|):/i’, $file)) { die(‘Illegal protocol detected.’); } // 或者，只允许已知安全的字符集 if (!preg_match(‘/^[a-zA-Z0-9_\-\.]+$/’, $file)) { die(‘Invalid filename.’); } - 使用安全的文件操作函数：对于只需要读取内容不需要执行的情况，使用
file_get_contents()代替include()。但同样要对参数进行过滤。
4.2 配置层：收紧PHP环境
服务器的默认配置往往为了方便而牺牲安全，必须主动加固。
allow_url_fopen与allow_url_include：在生产环境中，强烈建议将allow_url_include设置为Off。这能直接阻断php://input、data://、http://等远程包含。allow_url_fopen可以根据实际需求决定，如果不需要从远程URL打开文件，也建议关闭。open_basedir：设置此指令可以将PHP可操作的文件限制在指定的目录树中，能有效限制目录遍历攻击的范围。例如：open_basedir = /var/www/html:/tmp。但要注意，它无法防御伪协议读取受限目录内的文件。disable_functions：在php.ini中，使用disable_functions禁用危险函数。对于命令执行类漏洞，即使攻击者注入了代码，也无法调用关键函数。建议禁用：system, exec, passthru, shell_exec, proc_open, popen, eval, assert, pcntl_exec等。这是一个非常重要的纵深防御措施。session.upload_progress.cleanup = Off：这是一个有点“反直觉”的配置。当它为On（默认）时，上传进度信息文件会被立即清理，难以利用。设为Off可以增加攻击者利用临时文件包含的难度，但会留下更多临时文件。需权衡利弊。
4.3 架构与运维层：最小权限与纵深防御
- Web服务器权限最小化：运行PHP-FPM或Apache进程的用户（如www-data）应该只拥有对Web根目录的必要读写权限，绝不能是root用户。严格限制其对
/etc、/proc、/var/log等系统目录的读取权限。 - 日志文件安全：将Web日志、系统日志的权限设置为仅root可读，或者让Web进程用户无法读取。例如，将
access.log的属主设为root，组设为adm，权限设为640。这能有效防御日志污染攻击。 - 定期更新与安全扫描：保持PHP版本、Web服务器、系统组件的最新状态，及时修补已知漏洞。使用静态代码分析工具（如SonarQube, PHPStan）和动态应用安全测试工具进行定期扫描。
- 部署Web应用防火墙：配置合理的WAF规则，可以拦截常见的伪协议攻击Payload（如包含
php://、../的请求）。但WAF是缓解手段，不能替代安全的代码。
4.4 漏洞检测与应急响应
- 代码审计：在开发流程中引入安全代码审计，重点关注所有包含用户输入的文件操作函数（
include, require, fopen, file_get_contents等）。 - 入侵检测：在服务器层面监控对
/proc/self/environ、/var/log/下日志文件的异常访问尝试。在应用层面，监控是否包含异常参数（如php://,data://）的请求。 - 应急响应：一旦发现被攻击，立即隔离服务器，分析访问日志定位攻击入口和Payload，修复漏洞，清理后门，并检查是否发生数据泄露。
5. 高级绕过技巧与防御对抗实录
安全是一场持续的攻防对抗。当基础防御措施到位后，攻击者会尝试各种奇技淫巧进行绕过。了解这些技巧，才能制定更稳固的防御策略。
5.1 编码与字符串处理绕过
当代码中对../或php等关键词进行简单替换或过滤时。
- 多重编码：
php://filter本身支持多重过滤器。例如，攻击者可能使用convert.iconv.UTF8.UTF7等过滤器，将Payload转换为另一种编码，以绕过基于关键词的匹配。 - URL编码：对特殊字符进行URL编码。例如，
php://可以写成%70%68%70%3a%2f%2f。一些简单的过滤可能不会递归解码。 - 协议拼接：利用某些环境下的字符串处理特性。例如，如果过滤了
php://，可以尝试php:/*/filter/...（利用注释）或PHP://（大小写绕过，Windows系统不敏感，Linux下PHP默认包装器注册可能区分大小写，但最好统一处理）。
5.2 利用非常规包含函数与上下文
并非只有include/require危险。
file_exists()、is_file()等：这些函数也会触发伪协议处理器。虽然它们不执行代码，但可以用来探测文件或协议是否存在，是信息收集的一部分。curl扩展：如果代码使用curl从用户提供的URL获取数据，攻击者可以提供file://协议来读取本地文件，造成SSRF（服务器端请求伪造）和本地文件读取的组合漏洞。simplexml_load_file()、DOMDocument::load()：这些XML处理函数也支持伪协议。如果XML外部实体（XXE）功能未禁用，攻击者可以通过php://filter读取文件内容并作为实体注入到XML输出中。
5.3 利用临时文件与竞争条件
这是一种更隐蔽的攻击方式。
- 利用
php://temp或php://memory创建临时流，写入恶意代码。 - 结合一个存在竞争条件的文件操作（例如，先检查文件后缀是否合法，再移动文件），尝试在文件被删除或移动前的一瞬间去包含它。
- 这种攻击难度高，成功率低，但体现了攻击思路的多样性。
5.4 防御升级建议
面对高级绕过，防御策略也需要升级：
- 正则表达式强化：过滤规则应使用更严格的正则，并考虑递归解码和大小写问题。例如：
preg_match(‘/^[a-z0-9_\-\.]+$/i’, $file)只允许字母数字下划线横杠点，并锚定字符串开头结尾。 - 上下文感知过滤：如果业务需要接受URL，则应在指定上下文（如必须是http/https）下进行严格验证，而不是简单禁用所有协议。
- 使用安全的API：对于文件包含，尽可能使用框架提供的安全方法。例如，使用Twig或Blade等模板引擎，它们本身提供了安全的模板包含机制，隔离了代码执行。
- 虚拟文件系统与沙箱：在极端安全要求下，可以考虑使用
php.ini的open_basedir或容器技术，将应用锁死在独立的文件系统视图内。
在我多年的安全审计经历中，见过太多因为一个微不足道的include($page . ‘.php’)而全线崩溃的系统。伪协议攻击之所以经典，是因为它直指Web安全的核心矛盾：功能的便利性与输入的可控性。作为开发者，我们必须时刻对用户输入保持“零信任”态度，采用白名单、最小权限、纵深防御的原则来构建应用。而作为防御者，理解攻击者的每一步操作和每一种绕过手法，才能提前布防，将风险扼杀在萌芽状态。安全没有银弹，唯有时刻警惕、持续学习、层层设防。
