PHP伪协议深度解析：从数据流操作到安全攻防实战

1. 项目概述：为什么我们需要深入理解PHP伪协议？

在PHP开发和安全研究领域，“伪协议”是一个既熟悉又陌生的概念。很多开发者知道file_get_contents('php://input')可以获取POST原始数据，也听说过php://filter在文件包含漏洞中的神奇作用，但对其背后的机制、家族成员以及潜在的风险与价值，往往缺乏系统性的认知。实际上，PHP伪协议是PHP为访问各种输入/输出流（I/O streams）而设计的一套强大且灵活的封装器，它像一套“万能钥匙”，能够以统一的方式读写数据，无论这些数据来自标准输入、输出、内存，还是经过特定编码转换。

我最初接触伪协议是在处理文件上传和API数据接收时，当时只觉得php://input比$_POST更“原始”、更可靠。后来在安全审计中，看到攻击者利用php://filter配合文件包含来读取源码，才惊觉其威力。这促使我花了大量时间深入研究官方文档、测试各种场景，甚至分析PHP内核中关于流处理的源码片段。我发现，伪协议远不止于那几个常见用法，它贯穿于PHP的高效数据处理、临时文件管理、甚至是一些特定场景下的“黑魔法”中。理解它，不仅能让你写出更健壮、更高效的代码（比如安全地处理用户上传、灵活地操作数据流），更能让你在面临安全挑战时，具备一双“火眼金睛”，既能加固自身应用，也能理解攻击者的思路。

简单来说，本文旨在为你彻底拆解PHP伪协议。无论你是想优化数据处理的PHP开发者，还是关注应用安全的工程师，或是正在学习Web渗透测试的研究者，这些内容都将为你提供从原理到实战的完整视角。我们将从最常见的php://input和php://filter入手，逐步深入到data://、phar://等协议，并探讨它们在正常开发与安全攻防中的典型应用与对抗。让我们开始吧。

2. PHP伪协议家族全解析：核心成员与工作机制

PHP伪协议并非一个单一的协议，而是一个家族，它们都以php://或data:等为前缀，但各自承担着不同的职责。要理解它们，首先要明白PHP中“流”的概念。你可以把流想象成一条水管，数据是水流，而伪协议就是连接水源（数据来源）和水龙头（我们的PHP脚本）的各种特殊接头。这些接头规定了水从哪里来（输入）、到哪里去（输出），以及水流是否要经过过滤（编码转换）。

2.1php://input：原始POST数据的读取器

这是最常用的伪协议之一。当客户端（如浏览器）通过POST方法发送数据时，通常我们使用$_POST超全局变量来获取。但$_POST只能解析application/x-www-form-urlencoded或multipart/form-data这两种编码格式的数据。如果你接收的是JSON、XML等原始数据，$_POST就无能为力了。

这时，php://input就派上用场了。它是一个只读流，允许你读取请求的原始数据（raw data）。无论客户端发送的是什么格式，它都能原封不动地读取出来。

工作原理与示例：

// 假设客户端发送了一个JSON body: {"name": "test", "id": 1} $rawData = file_get_contents('php://input'); // $rawData 现在是字符串：'{"name": "test", "id": 1}' $dataArray = json_decode($rawData, true); // $dataArray 现在是关联数组：['name' => 'test', 'id' => 1]

重要提示：php://input中的数据只能读取一次。如果你用file_get_contents读了一次，再读就是空字符串。这是因为数据流是单向的。此外，当请求的Content-Type是multipart/form-data时（通常用于文件上传），php://input是无效的，这是PHP的一个已知限制。

开发中的实用场景：

1. 构建RESTful API接口：统一使用php://input接收JSON或XML请求体，再进行解析，代码更清晰。
2. 处理非表单数据：如接收来自硬件设备或其他服务的特定格式数据包。
3. 安全考虑：有时直接操作原始流比依赖$_POST（可能被register_globals等古老设置影响）更可控。

2.2php://output：直接写入输出缓冲的通道

与input相对，php://output是一个只写流，允许你像写文件一样，直接将内容写入输出缓冲区。这听起来和echo或print很像，但在某些流式处理的场景下非常有用。

示例：

$fp = fopen('php://output', 'w'); fwrite($fp, "Hello, World via php://output!\n"); fclose($fp); // 这行内容会直接发送到浏览器。

实际应用：

• 生成动态文件供下载：你可以设置好HTTP头（如Content-Disposition: attachment），然后通过php://output流式写入CSV或Excel文件的内容，无需在服务器上生成临时文件，极大节省磁盘I/O和空间。

  header('Content-Type: text/csv'); header('Content-Disposition: attachment; filename="export.csv"'); $output = fopen('php://output', 'w'); fputcsv($output, ['姓名', '年龄', '城市']); // 写入表头 // ... 循环从数据库获取数据并写入 fputcsv($output, ['张三', 25, '北京']); fclose($output); exit; // 确保脚本结束，不输出额外内容

2.3php://filter：数据流的“变形金刚”

这是伪协议中最复杂、也最强大（同时被滥用得最多）的一员。php://filter本身不是一个数据源，而是一个“过滤器链”，它可以对另一个流进行读取或写入时的编码转换。其基本语法是：php://filter/read=<过滤器链>/resource=<目标资源>或php://filter/write=<过滤器链>/resource=<目标资源>。

核心过滤器举例：

• string.rot13： 对数据进行ROT13编码（字母移位13位）。
• string.toupper/string.tolower： 转换大小写。
• convert.base64-encode/convert.base64-decode： Base64编解码。
• convert.quoted-printable-encode/convert.quoted-printable-decode： Quoted-Printable编解码。
• zlib.deflate/zlib.inflate： Zlib压缩/解压。
• bzip2.compress/bzip2.decompress： Bzip2压缩/解压。

常规开发用途：

// 读取一个文件，并自动进行Base64编码 $content = file_get_contents('php://filter/read=convert.base64-encode/resource=config.ini'); echo $content; // 输出的是config.ini文件的Base64编码字符串 // 写入数据时自动压缩 $data = 'Some very long repetitive text...'; file_put_contents('php://filter/write=zlib.deflate/resource=compressed.log', $data); // compressed.log 文件中存储的是压缩后的二进制数据

安全领域的“双刃剑”：php://filter在安全测试中声名狼藉，主要是因为它在“文件包含”漏洞中的利用。如果一段代码不当地包含了用户可控的文件路径，例如include($_GET['page'] . '.php');，攻击者可以传入page=php://filter/read=convert.base64-encode/resource=index，最终服务器会尝试包含index.php文件，但会先将其内容Base64编码。由于include会执行PHP代码，而Base64编码后的文本不是有效的PHP代码，所以不会执行，但编码后的源码内容会被直接输出到页面上。攻击者解码后即可获得网站源代码，这被称为“源码泄露”。这是理解PHP伪协议安全风险的关键案例。

2.4php://memory与php://temp：高效的内存与临时文件操作

这两个协议用于在内存或临时文件中操作数据，避免了频繁的磁盘读写，提升性能。

• php://memory： 将数据存储在内存中。读写速度极快，但受限于内存大小。
• php://temp： 默认也会先使用内存（通常是一个阈值，如2MB），当数据量超过阈值后，会自动将数据写入系统临时目录的一个临时文件中。这在大数据处理时非常有用，兼具了速度和容量。

示例：

// 使用 php://memory 处理图像 $img = imagecreate(100, 100); $bg = imagecolorallocate($img, 255, 255, 255); // ... 一些绘图操作 ob_start(); // 开启输出缓冲 imagepng($img); $imageData = ob_get_clean(); // 获取图片二进制数据 imagedestroy($img); // 将图片数据写入内存流，并计算MD5 $memStream = fopen('php://memory', 'r+'); fwrite($memStream, $imageData); rewind($memStream); // 将指针移回开头 $md5 = md5(stream_get_contents($memStream)); fclose($memStream); echo "Image MD5: $md5";

2.5data://：将数据直接嵌入URI

data://协议并非PHP独有，它符合RFC 2397标准，允许在URI中直接嵌入数据。格式为：data:[<mediatype>][;base64],<data>。

在PHP中的使用：

// 直接读取嵌入的文本 $text = file_get_contents('data://text/plain,Hello World!'); echo $text; // 输出： Hello World! // 读取Base64编码的数据 $base64Data = file_get_contents('data://text/plain;base64,SGVsbG8gV29ybGQh'); echo $base64Data; // 输出： Hello World! // 甚至可以“包含”一段PHP代码（危险！） // 假设有漏洞代码：include($_GET['file']); // 攻击者可以传入：file=data://text/plain,<?php phpinfo();?> // 如果allow_url_include=On，这段代码会被包含并执行！

安全警告：data://协议与allow_url_include配置紧密相关。在PHP安全配置中，绝对应该将allow_url_include设置为Off，这是防止远程文件包含（RFI）攻击的关键措施之一。在allow_url_include=Off的情况下，data://协议通常无法用于包含执行代码。

2.6phar://：PHP归档文件的访问接口

phar://是用于访问PHAR（PHP Archive）文件内部条目的流包装器。PHAR类似于Java的JAR，可以将整个PHP应用打包成一个文件。虽然它本身功能正当，但在反序列化漏洞利用中常被用作“跳板”，因为它能反序列化其元数据中的对象，可能触发危险的__wakeup()或__destruct()魔术方法，从而结合其他漏洞实现代码执行。由于其利用链较为复杂，且需要特定条件，这里不再深入展开，但你需要知道它是伪协议家族中与安全高度相关的一员。

3. 核心细节解析：php://filter的链式过滤器与编码技巧

php://filter的强大之处在于支持过滤器链。你可以将多个过滤器像管道一样连接起来，让数据依次通过处理。语法是用|符号分隔多个过滤器。

3.1 过滤器链的构造与执行顺序

格式：php://filter/read=<filter1>|<filter2>|<filter3>/resource=<file>数据会先从<file>中读取，然后依次通过filter1、filter2、filter3进行处理，最后才交给file_get_contents()等函数。

示例：将文件内容先ROT13编码，再Base64编码：

$encoded = file_get_contents('php://filter/read=string.rot13|convert.base64-encode/resource=secret.txt'); echo $encoded;

假设secret.txt内容是Hello，那么：

1. Hello经过string.rot13变成Uryyb。
2. Uryyb经过convert.base64-encode变成VXJ5eWI=。 最终输出VXJ5eWI=。

逆向操作（解码链）：

// 假设我们有一个经过 rot13 -> base64 编码的字符串存储在 encoded.txt 里，内容是 VXJ5eWI= $decoded = file_get_contents('php://filter/read=convert.base64-decode|string.rot13/resource=encoded.txt'); echo $decoded; // 输出： Hello

注意，过滤器的执行顺序是从左到右。解码时顺序必须与编码时相反。

3.2 利用过滤器进行字符串处理与转换

除了安全测试，在正常开发中，过滤器链可以优雅地处理一些数据转换任务。

场景：读取一个GBK编码的文本文件，并转换为UTF-8输出。虽然PHP有mb_convert_encoding函数，但使用流过滤器可以更“流式”地处理大文件。

// 注意：convert.iconv.* 过滤器需要iconv扩展支持，且PHP版本通常需>=5.4 $utf8Content = file_get_contents('php://filter/read=convert.iconv.GBK/UTF-8/resource=gbk_file.txt'); file_put_contents('utf8_file.txt', $utf8Content);

场景：实时压缩并写入日志。

$logMessage = date('Y-m-d H:i:s') . " - User 'admin' logged in from IP " . $_SERVER['REMOTE_ADDR'] . "\n"; // 使用过滤器链：先写入，如果启用压缩则进行deflate压缩 $filterChain = 'write=string.toupper'; // 先转大写 if ($enableCompression) { $filterChain .= '|zlib.deflate'; // 再压缩 } file_put_contents("php://filter/{$filterChain}/resource=app.log", $logMessage, FILE_APPEND);

3.3php://filter在安全测试中的典型利用姿势

这是本节的重点。理解攻击者如何利用它，是做好防御的第一步。

利用条件：

1. 存在文件包含漏洞，例如include($file)、require_once($_GET['module']等，且$file用户部分可控。
2. 目标文件具有可读权限。
3. allow_url_include配置通常不影响php://filter对本地文件的读取和编码，因为它被视为一个本地协议。

利用步骤：

1. 探测漏洞：尝试包含一个已知存在的文件，如?file=../../etc/passwd（Linux）或?page=index（可能补全为index.php）。
2. 构造Payload：当发现包含成功（可能报错或显示内容），但直接包含.php文件不会显示源码（因为会被执行）时，使用php://filter进行编码读取。
   • Payload示例1（Base64编码）：

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

     页面会输出一串Base64字符串，解码即可得源码。
   • Payload示例2（ROT13编码）：

     ?file=php://filter/read=string.rot13/resource=config.php

     页面输出ROT13编码的文本，解码即可。ROT13有时可以绕过一些简单的过滤。
   • Payload示例3（多重编码绕过）：如果WAF或代码简单过滤了base64-encode等关键词，可以尝试多重编码或使用其他过滤器。

     ?file=php://filter/read=convert.iconv.UTF-8.UTF-7/resource=index.php

     将UTF-8转换为UTF-7，可能会产生可读的（但混乱的）输出。
3. 解码获取源码：将获取到的编码内容保存下来，使用在线的或本地的解码工具（如base64_decode、str_rot13）进行解码。

防御之道：

• 杜绝动态包含：尽可能避免直接包含用户输入变量。如果必须，请使用白名单机制。

  $allowedPages = ['home', 'about', 'contact']; $page = $_GET['page'] ?? 'home'; if (!in_array($page, $allowedPages)) { $page = 'home'; } include($page . '.php');

• 严格过滤输入：对用户输入进行严格校验和过滤，例如检查是否包含路径遍历符（../）或协议包装器（php://，data://等）。

  $file = $_GET['file']; if (preg_match('/\.\.\/|php:\/\/|data:\/\//i', $file)) { die('Invalid input!'); } // 注意：过滤规则需要精心设计，防止被绕过。

• 设置PHP配置：确保allow_url_include和allow_url_fopen在生产环境中为Off。这能有效阻断data://、http://等远程协议的包含，但对php://filter读取本地文件无效。
• 使用绝对路径：使用基于文档根目录的绝对路径进行包含，减少不确定性。

4. 实操过程：构建一个安全的文件包含与数据处理模块

理论说了很多，现在我们动手构建一个兼具功能性和安全性的模块。这个模块需要实现两个功能：1) 安全地包含模板文件；2) 安全地接收并处理原始POST数据（如JSON）。

4.1 安全模板包含器的实现

假设我们有一个简单的CMS，需要根据URL参数加载不同的页面模板。

不安全的反例：

// insecure_include.php $template = $_GET['t'] ?? 'index'; include('./templates/' . $template . '.php');

攻击者可以利用?t=../../../../etc/passwd或?t=php://filter/read=convert.base64-encode/resource=../config进行攻击。

安全的正向实现：

// secure_template_loader.php class TemplateLoader { private $templateDir; private $allowedTemplates; public function __construct($dir = './templates') { // 规范化模板目录，确保是绝对路径且末尾有斜杠 $this->templateDir = realpath($dir) . DIRECTORY_SEPARATOR; if ($this->templateDir === false) { throw new Exception('Template directory does not exist.'); } // 预定义允许的模板白名单 $this->allowedTemplates = ['home', 'article', 'gallery', 'contact']; } public function load($templateName) { // 1. 白名单校验 if (!in_array($templateName, $this->allowedTemplates)) { $templateName = 'home'; // 默认回退 // 或者记录日志并抛出异常 // throw new Exception('Invalid template requested.'); } // 2. 构造绝对路径 $templatePath = $this->templateDir . $templateName . '.php'; // 3. 二次验证：路径是否仍在允许的目录内（防止目录遍历拼接白名单绕过） if (strpos(realpath($templatePath), $this->templateDir) !== 0) { // 请求的模板文件不在模板目录内，可能是目录遍历攻击 error_log("Potential directory traversal attack detected: $templateName"); throw new Exception('Access denied.'); } // 4. 检查文件是否存在且可读 if (!is_readable($templatePath)) { throw new Exception("Template '$templateName' not found or not readable."); } // 5. 安全包含 include($templatePath); } } // 使用示例 $loader = new TemplateLoader(); try { $t = $_GET['t'] ?? 'home'; $loader->load($t); } catch (Exception $e) { // 优雅地处理错误，例如显示一个友好的404页面 include('./templates/error.php'); }

实现要点解析：

1. 白名单机制：这是最核心的防御，只允许加载预定义的模板。
2. realpath()函数：它解析所有符号链接和../，返回规范的绝对路径。用于验证最终路径是否仍在预设目录下。
3. strpos()检查：确保realpath后的文件路径是以我们设定的模板目录开头的，这是防御目录遍历的黄金标准。
4. is_readable()检查：在包含前做最后一道检查，避免因文件不存在导致的警告或错误。

4.2 使用php://input安全接收并处理JSON API请求

构建一个简单的API端点，用于接收用户创建的订单数据（JSON格式）。

// api_create_order.php header('Content-Type: application/json'); // 1. 只允许POST方法 if ($_SERVER['REQUEST_METHOD'] !== 'POST') { http_response_code(405); // Method Not Allowed echo json_encode(['error' => 'Only POST method is allowed.']); exit; } // 2. 可选：检查Content-Type，虽然不是必须，但能增加健壮性 $contentType = $_SERVER['CONTENT_TYPE'] ?? ''; if (stripos($contentType, 'application/json') === false) { // 可以宽松处理，仅记录日志；也可以严格拒绝 // http_response_code(415); // echo json_encode(['error' => 'Unsupported Media Type. Expecting application/json.']); // exit; } // 3. 从php://input获取原始数据 $rawInput = file_get_contents('php://input'); if ($rawInput === false || empty($rawInput)) { http_response_code(400); echo json_encode(['error' => 'Request body is empty or could not be read.']); exit; } // 4. 解码JSON $data = json_decode($rawInput, true); if (json_last_error() !== JSON_ERROR_NONE) { http_response_code(400); echo json_encode(['error' => 'Invalid JSON format: ' . json_last_error_msg()]); exit; } // 5. 数据验证（示例） $requiredFields = ['product_id', 'quantity', 'user_id']; foreach ($requiredFields as $field) { if (!isset($data[$field])) { http_response_code(422); // Unprocessable Entity echo json_encode(['error' => "Missing required field: $field"]); exit; } } // 更详细的验证：类型、范围等 if (!is_int($data['quantity']) || $data['quantity'] <= 0) { http_response_code(422); echo json_encode(['error' => 'Quantity must be a positive integer.']); exit; } // 6. 业务逻辑处理（模拟） $orderId = mt_rand(1000, 9999); // ... 这里通常是插入数据库的操作 // 7. 返回成功响应 http_response_code(201); // Created echo json_encode([ 'success' => true, 'message' => 'Order created successfully.', 'order_id' => $orderId, 'data_received' => $data // 在实际环境中不应返回敏感数据 ]);

实操心得：

• php://input的不可重复读：在这个脚本中，file_get_contents('php://input')只调用了一次。如果你需要在多个地方使用原始数据，应该将其存储到一个变量中，而不是重复读取。
• 错误处理：对file_get_contents的失败和json_decode的失败都做了处理，并返回了恰当的HTTP状态码，这是构建友好API的基础。
• 数据验证：永远不要信任客户端传来的数据。即使前端做了验证，后端也必须进行严格的校验。这里使用了简单的存在性检查和类型检查，生产环境应使用更强大的验证库（如respect/validation或illuminate/validation）。
• 安全输出：在成功的响应中，我们回显了接收到的数据用于演示。在生产环境中，应避免将未经处理的用户输入直接包含在响应中，以防潜在的XSS（如果API响应被嵌入HTML）或信息泄露。

5. 常见问题、安全陷阱与排查技巧实录

在实际开发和安全审计中，关于PHP伪协议的问题层出不穷。下面我整理了一些典型场景和排查思路。

5.1file_get_contents(‘php://input’)返回空值？

这是新手最常遇到的问题。可能的原因和排查步骤：

1. 请求方法错误：php://input只对POST、PUT、PATCH等带有请求体的方法有效。对于GET、HEAD、OPTIONS等方法，它永远是空的。首先检查$_SERVER['REQUEST_METHOD']。
2. enctype="multipart/form-data"：当表单使用enctype="multipart/form-data"（文件上传时必用）时，php://input是不可用的。这是PHP的底层限制。此时应该使用$_POST和$_FILES。
3. 数据已被读取：如前所述，php://input流是只读一次的。检查代码中是否在其他地方（例如框架的底层、全局中间件）已经读取过它。
4. 配置问题：极少数情况下，allow_url_include的配置可能会影响（尽管官方文档说php://input不受其影响）。确保它不是被错误地禁用了某个相关扩展。通常这不是主因。

排查命令/代码：

// 在脚本开头加入调试信息 error_log("Request Method: " . $_SERVER['REQUEST_METHOD']); error_log("Content-Type: " . ($_SERVER['CONTENT_TYPE'] ?? 'Not Set')); $input = file_get_contents('php://input'); error_log("php://input length: " . strlen($input)); error_log("php://input preview (first 100 chars): " . substr($input, 0, 100)); var_dump($input); // 或直接输出查看

5.2 如何防御php://filter等伪协议在文件包含中的利用？

除了前面提到的白名单和路径检查，还有一些进阶思路：

1. 禁用危险的包装器：在PHP 7.4及以上版本，你可以使用stream_wrapper_unregister()函数来注销特定的流包装器。但需谨慎，可能影响正常功能。

   // 在应用初始化时调用（风险高，需全面测试） if (in_array('php', stream_get_wrappers())) { // 注意：这会影响所有php://协议的使用，包括php://input, php://memory等！ // stream_wrapper_unregister('php'); } // 更常见的是，如果你确定不用data://和phar://，可以禁用它们 foreach (['data', 'phar'] as $wrapper) { if (in_array($wrapper, stream_get_wrappers())) { @stream_wrapper_unregister($wrapper); } }

   警告：此操作影响全局，且不可逆。在生产环境使用前，必须在测试环境充分验证所有依赖流包装器的功能（如Composer、某些图像处理库）是否正常。

2. 使用open_basedir限制：在php.ini中设置open_basedir，将PHP可操作的文件限制在指定的目录树中。这能有效防止目录遍历攻击访问系统敏感文件（如/etc/passwd），但对php://filter读取网站目录内的源码文件防御有限。

   open_basedir = /var/www/html/your_project:/tmp

3. 代码审计与静态分析：定期使用工具（如phpcs配合安全规则、phan、psalm）扫描代码库，查找不安全的文件包含函数（include,require,include_once,require_once）及其动态变量参数。

5.3data://协议利用的条件与限制

很多文章会提到data://协议可以用于执行代码，但实际利用条件非常苛刻：

1. allow_url_include必须为On：这是最关键的条件。自PHP 5.2起，该配置默认就是Off。任何安全的PHP生产环境都应保持其为Off。你可以通过phpinfo()或ini_get('allow_url_include')来检查。
2. allow_url_fopen通常也需要为On：虽然data://主要用于包含，但allow_url_fopen的设置有时也会产生影响。
3. 有效的PHP标签：通过data://传递的数据必须包含有效的PHP标签<?php ... ?>，才会被解析执行。如果只是文本，则只会被当作文本包含。
4. 长度限制：data://URI有长度限制，不适合传递大量代码。

检查与加固：

• 在php.ini中确认：

  allow_url_fopen = Off allow_url_include = Off

• 如果无法修改全局php.ini（如共享主机），可以在.htaccess（Apache）或Nginx配置的location块中尝试设置：

  php_admin_value allow_url_include Off

  或者在脚本开头使用ini_set('allow_url_include', '0');（注意：某些安全模式或配置可能禁止运行时修改）。

5.4 使用php://filter进行编码转换时的字符集陷阱

当你使用convert.iconv.*过滤器进行字符集转换时，如果源文件或目标字符集指定错误，会导致乱码或转换失败。

案例：一个UTF-8编码的PHP文件，其中包含中文字符。如果你错误地将其当作GBK读取并转换：

$content = file_get_contents('php://filter/read=convert.iconv.GBK/UTF-8/resource=utf8_file.php'); // 如果原文件是UTF-8，这里指定源为GBK会导致转换错误，$content出现乱码。

排查技巧：

1. 先用mb_detect_encoding()或iconv函数检测文件的实际编码。
2. 在测试时，先对一小段样本数据进行转换测试。
3. 对于不确定编码的文件，可以尝试//TRANSLIT或//IGNORE后缀来处理无法转换的字符，但这可能丢失数据。

   // 忽略无法转换的字符 $filter = 'convert.iconv.UTF-8.GBK//IGNORE'; // 或尝试音译 $filter = 'convert.iconv.UTF-8.GBK//TRANSLIT';

5.5 伪协议与文件上传漏洞的结合

攻击者有时会利用文件上传漏洞，上传一个包含恶意代码的图片（图片马），然后结合文件包含漏洞和php://filter来执行。例如，上传一个.jpg文件，内容为<?php phpinfo();?>。如果服务器仅检查文件后缀，并且存在文件包含漏洞，攻击者可能通过包含这个图片文件来执行PHP代码。

防御策略：

1. 文件内容检查：使用getimagesize()、exif_imagetype()等函数验证上传的文件确实是有效的图片，而不仅仅是后缀是图片。
2. 重命名文件：使用随机字符串（如md5(uniqid())）重命名上传的文件，并避免使用用户提供的原始文件名。
3. 设置存储目录无执行权限：将上传的文件存储在Web根目录之外，或者确保该目录的.htaccess（Apache）中设置了php_flag engine off，防止该目录下的任何文件被解析为PHP。
4. 使用白名单验证MIME类型：不要依赖客户端传来的$_FILES[‘file’][‘type’]，而是使用服务器的文件信息函数（如finfo_file()）来检测真实的MIME类型。

   $finfo = finfo_open(FILEINFO_MIME_TYPE); $mime = finfo_file($finfo, $_FILES['uploaded_file']['tmp_name']); finfo_close($finfo); $allowedMimes = ['image/jpeg', 'image/png', 'image/gif']; if (!in_array($mime, $allowedMimes)) { die('Invalid file type.'); }

理解PHP伪协议，就像掌握了一把双刃剑。在开发者手中，它是处理数据流、提升性能的利器；在攻击者眼中，它可能成为探测系统、获取源码的跳板。我的经验是，永远不要仅仅满足于知道某个函数或协议怎么用，多问一句“它为什么这样工作？”和“滥用它会怎样？”，才能在编码时构建起更坚固的安全防线。对于伪协议，关键在于严格管控用户输入、遵循最小权限原则、并时刻保持对数据流边界的清晰认知。