1. 从一个“意外”的漏洞利用说起几年前我在一次内部安全审计中遇到一个非常典型的场景。一个看似普通的文件上传功能前端做了白名单校验只允许上传.jpg、.png等图片格式。后端也做了检查通过pathinfo($_FILES[file][name], PATHINFO_EXTENSION)获取扩展名确认是图片后才移动到指定目录。从逻辑上看似乎无懈可击。然而攻击者上传了一个名为shell.jpg的文件内容却是?php phpinfo(); ?。服务器竟然成功执行了这段代码输出了PHP配置信息。问题出在哪里后端在保存文件时使用了用户可控的文件名拼接路径时没有过滤形成了/uploads/shell.jpg。但关键在于攻击者在后续的请求中并没有直接访问这个文件而是通过一个查询参数构造了这样的请求/index.php?pagephp://filter/readconvert.base64-encode/resource/uploads/shell.jpg。这个奇怪的php://filter就是今天要深入探讨的主角之一——PHP伪协议。这个案例让我意识到很多开发者甚至是有一定经验的开发者对PHP伪协议的理解都停留在“听说过”或者“知道file_get_contents能用php://input”的层面。实际上PHP伪协议是一个强大且危险的双刃剑。它既是开发者处理数据流、封装操作的利器也是攻击者进行文件包含、代码执行、信息泄露的绝佳跳板。理解它不仅是为了写出更健壮的代码更是构建安全防线的必修课。本文将带你彻底拆解PHP伪协议从核心概念到工作机制从安全应用到高危漏洞让你不仅能看懂更能用对、防住。2. 伪协议的本质流包装器的魔法在深入具体协议之前我们必须先理解“伪协议”这个概念在PHP里到底意味着什么。它听起来有点“虚假”但实际上它是一种极其强大的抽象机制。2.1 流Stream的概念你可以把“流”想象成一条数据管道。无论是从本地文件读取内容从网络下载数据还是从压缩包中解压文件在程序看来都是从一个“源头”通过一条“管道”流向你的变量。PHP用“流”这个概念统一了这些不同数据源的操作接口。传统的fopen()、file_get_contents()等函数其第一个参数通常是一个类似/path/to/file.txt的路径或者http://example.com/data的URL。PHP内核会识别这个字符串的“协议”部分如file://、http://然后调用对应的“流包装器”来处理后续的打开、读取、写入等操作。2.2 伪协议Wrapper是什么PHP内置了一些特殊的流包装器它们处理的“协议”并非真实的网络协议如HTTP、FTP而是PHP为了完成特定功能而虚拟出来的因此被称为“伪协议”。这些伪协议的名称都以php://开头。核心价值在于它们允许你以操作“文件流”的方式去访问一些并非真实文件的数据源。比如php://input让你能像读文件一样读取HTTP请求的原始主体Raw Body。php://output让你能像写文件一样直接向HTTP响应体输出内容。php://temp或php://memory在内存中创建一个临时“文件”进行数据缓存无需磁盘I/O。这种抽象带来了巨大的灵活性。开发者可以用一套熟悉的文件操作函数fopenfwritefreadfile_get_contents等来处理各种来源的数据极大地简化了代码。2.3 与真实协议和文件系统的关系为了更清晰我们可以做一个对比特性真实文件/协议 (如file://,http://)PHP伪协议 (如php://)数据源磁盘文件、远程服务器资源PHP运行时环境提供的虚拟资源请求体、输出流、内存、过滤器链等目的访问外部存储或网络服务在PHP脚本内部进行数据流封装、转换和访问操作方式通过标准文件I/O函数同样通过标准文件I/O函数接口一致安全性受文件系统权限、网络策略限制完全在PHP脚本上下文中运行其行为和安全性与PHP配置及代码逻辑强相关关键在于最后一点。因为伪协议的操作发生在PHP内部所以它绕过了很多外部限制。一个经典的错误认知是“我禁用了allow_url_fopen和allow_url_include文件包含就安全了。” 但php://伪协议不受这两个配置项的影响它只受allow_url_include影响且仅针对include类函数而allow_url_fopen是针对http://、ftp://这类真实网络协议的。这是很多漏洞产生的根源。3. 核心伪协议深度拆解与实战PHP提供了多个伪协议每个都有其特定的用途和语法。下面我们挑选最常用、也最常出问题的几个进行详解。3.1 php://input读取原始POST数据的利器与险坑这是最著名的伪协议。它允许你读取POST请求的原始数据Raw Data而不是经过PHP解析后的$_POST数组。基本语法php://input可支持操作只读。常用函数file_get_contents(‘php://input’)为什么需要它当客户端发送的数据不是标准的application/x-www-form-urlencoded或multipart/form-data格式时$_POST是空的。例如发送JSON数据Content-Type: application/json发送XML数据使用PUT、DELETE等HTTP方法这时php://input是获取请求体的唯一可靠方式。实战示例接收JSON API请求// 客户端发送POST /api/user, Body: {name:John, age:30} $rawData file_get_contents(php://input); $userData json_decode($rawData, true); if (json_last_error() JSON_ERROR_NONE) { echo Hello, . $userData[name]; } else { http_response_code(400); echo Invalid JSON; }安全风险与注意事项内存消耗file_get_contents(‘php://input’)会一次性将整个请求体读入内存。如果攻击者发送一个巨大的文件如几个G会瞬间耗尽服务器内存导致PHP进程崩溃DoS攻击。在生产环境中务必设置php.ini中的post_max_size来限制POST数据大小。仅能读取一次php://input流在读取后即失效。如果你在代码中多次调用file_get_contents(‘php://input’)第二次会得到空字符串。如果需要复用必须先将内容保存到变量中。与$HTTP_RAW_POST_DATA的区别这是另一个获取原始POST数据的方式但需要在php.ini中启用always_populate_raw_post_data且已在PHP 7.0后被移除。php://input是更现代和推荐的方式。enctype”multipart/form-data”时不可用当表单用于文件上传时php://input是无效的。这是PHP的设计使然。3.2 php://filter数据流的“变形金刚”这是功能最强大、也最常被攻击者利用的伪协议。它本身不是一个独立的数据源而是一个“过滤器链”可以附加在其他流如文件、php://input之上在读取或写入时对数据进行实时转换。基本语法php://filter/filters/resourcestreamfilters一个或多个过滤器用竖线|连接按顺序执行。stream目标资源如/etc/passwd、./config.php。常用过滤器convert.base64-encode/convert.base64-decode进行Base64编解码。string.rot13进行ROT13编码。string.toupper/string.tolower转换大小写。zlib.deflate/zlib.inflate进行Zlib压缩/解压。convert.iconv.*进行字符集转换需安装iconv扩展。实战示例1安全读取PHP源码我们知道直接include或file_get_contents一个.php文件得到的是执行后的输出而非源代码。但有时我们需要查看源码例如在可控环境下做代码审计。php://filter可以帮我们实现// 读取自身文件的源码并以Base64编码形式输出避免被直接执行 $source file_get_contents(php://filter/readconvert.base64-encode/resource . __FILE__); echo $source; // 输出的是Base64编码的源码解码即可得原始代码 // 输出类似PD9waHAgICBlY2hvICJIZWxsbyBXb3JsZCI7ID8实战示例2动态压缩输出// 将输出内容用gzip压缩后发送给浏览器 header(Content-Encoding: gzip); $fp fopen(php://filter/writezlib.deflate/resourcephp://output, w); fwrite($fp, This is a large amount of text that will be compressed...); fclose($fp);高危漏洞场景文件包含与代码执行这就是文章开头案例的原理。假设存在一个本地文件包含漏洞LFI// vulnerable.php $page $_GET[page]; include($page . .php);攻击者可以构造请求vulnerable.php?pagephp://filter/readconvert.base64-encode/resourceindexinclude函数试图包含php://filter/readconvert.base64-encode/resourceindex.php。PHP会先通过php://filter包装器读取index.php文件的内容。过滤器convert.base64-encode将源码转换为Base64编码。include试图执行这段“代码”。由于Base64编码的文本不是有效的PHP代码所以不会执行但include会将其内容作为文本输出到页面上攻击者看到Base64编码的源码解码后获得敏感信息如数据库配置。更危险的是一种称为“死亡绕过”的技巧。如果网站对包含的文件路径有后缀限制如必须.php或者有前缀限制如必须以./开头攻击者可以结合多个过滤器来绕过。例如先Base64解码一段恶意代码再包含它php://filter/readconvert.base64-decode/resourcedata://text/plain;base64,PD9waHAgZXZhbCgkX1BPU1RbY21kXSk7Pz4 // 其中 PD9waHAgZXZhbCgkX1BPU1RbY21kXSk7Pz4 是 ?php eval($_POST[cmd]);? 的Base64编码 // convert.base64-decode 会将其解码还原成可执行的PHP代码防御之道绝对不要将用户输入直接传递给include、require、file_get_contents等函数。必须使用白名单机制严格限定可包含的文件名。3.3 php://output 与 php://stdout/stderrphp://output这是一个只写流写入它的所有数据会直接进入输出缓冲区最终作为HTTP响应体发送给客户端。echo和print语句在内部可以看作是对这个流的操作。$fp fopen(php://output, w); fwrite($fp, Writing directly to output buffer.\n); fclose($fp);php://stdout/php://stderr这两个主要用于命令行CLI模式分别对应标准输出和标准错误流。在Web环境下它们通常和php://output指向同一个地方。使用场景当你需要以流式方式逐步生成大量输出而不是在内存中拼接完整个字符串再echo时使用php://output可以降低内存峰值使用量。3.4 php://temp 与 php://memory临时数据容器这两个伪协议用于创建临时数据流行为类似文件句柄但数据存储在内存或临时文件中。php://memory将数据存储在内存中。速度快但受memory_limit限制。php://temp默认先使用内存当数据量超过一定阈值默认为2MB可通过/maxmemory:NNN指定如php://temp/maxmemory:524288后会自动将数据写入系统临时目录的一个真实文件中。实战示例处理上传的CSV文件// 假设上传了一个CSV文件我们不想先保存到磁盘而是直接在内存中处理 $uploadedFile $_FILES[csv][tmp_name]; // 这是PHP已保存的临时文件 // 但我们用php://memory来演示创建新流 $fp fopen(php://memory, r); // 生成一些CSV数据写入 fputcsv($fp, [Name, Email, Phone]); fputcsv($fp, [Alice, aliceexample.com, 123456]); // 将指针移回开头准备读取 rewind($fp); // 读取并输出 while (($line fgets($fp)) ! false) { echo htmlspecialchars($line) . br; } fclose($fp); // 脚本结束后php://memory中的内容自动释放无需清理注意事项php://memory创建的数据流仅在当前请求的生命周期内存在请求结束后自动销毁。php://temp产生的临时文件也会在文件句柄关闭后被PHP自动删除。3.5 data:// 协议内联数据流虽然前缀不是php://但data://协议也常被归为伪协议讨论且同样危险。它允许在URI中直接嵌入数据。基本语法data://[mediatype][;base64],datamediatype可选MIME类型如text/plainimage/png。;base64可选表示数据是Base64编码的。data实际数据。示例// 读取内联的文本 $text file_get_contents(data://text/plain,Hello World); echo $text; // 输出Hello World // 读取内联的Base64编码数据 $encoded file_get_contents(data://text/plain;base64,SGVsbG8gV29ybGQ); echo $encoded; // 输出Hello World高危漏洞场景当allow_url_include配置为On时强烈不建议data://协议可以直接用于包含并执行恶意代码。// 如果 allow_url_includeOn且存在文件包含漏洞 include($_GET[file]); // 攻击者传入?filedata://text/plain,?php system(id);? // 这将导致代码执行防御永远不要在生产环境中开启allow_url_include默认是关闭的。4. 伪协议在安全攻防中的典型场景理解了原理我们来看看攻击者如何利用它们以及我们该如何防御。4.1 场景一利用文件包含读取敏感文件这是最常见的利用方式如前文php://filter的示例。攻击路径include/require/file_get_contents等函数参数用户可控 - 构造php://filter读取/etc/passwd、config.php、../.env等。防御措施输入校验与白名单严格校验用户输入只允许包含已知、预定义的文件。避免动态包含尽可能使用静态包含。如果必须动态使用basename()剥离目录并拼接固定的安全目录前缀。设置open_basedir将PHP可访问的文件限制在特定目录树内可以防止跨目录读取。但这并非绝对安全有被绕过的可能。代码审计检查所有文件操作函数的参数是否用户可控。4.2 场景二利用过滤器链绕过死亡代码有些防御代码会检查文件内容是否包含PHP标签?php、?等试图阻止上传Webshell。攻击者可以利用过滤器进行编码绕过。攻击路径将一句话木马?php eval($_POST[‘a’]);?进行Base64编码PD9waHAgZXZhbCgkX1BPU1RbJ2EnXSk7Pz4上传一个内容为该Base64字符串的“图片”文件shell.jpg。利用文件包含漏洞包含php://filter/readconvert.base64-decode/resourceuploads/shell.jpgconvert.base64-decode过滤器会将文件内容解码还原出原始的一句话木马代码并被include执行。防御措施禁用危险函数在php.ini中设置disable_functions eval, system, exec, shell_exec, passthru, ...。即使代码被包含关键函数也无法执行。文件内容检查不仅检查扩展名还要使用exif_imagetype()或getimagesize()检查上传文件是否为真实的图片或进行内容渲染验证。存储重命名上传文件后使用随机生成的文件名如UUID保存并彻底丢弃原始文件名避免通过路径猜测访问。Web目录隔离确保上传目录位于Web根目录之外或者配置Web服务器如Nginx禁止该目录下的PHP文件执行。4.3 场景三利用php://input进行代码执行在某些特定配置下php://input可与include结合导致代码执行。攻击路径需要allow_url_includeOn并且存在一个本地文件包含漏洞但攻击者无法上传文件。攻击者可以发送一个POST请求Body为?php phpinfo(); ?然后包含php://input。GET /vuln.php?filephp://input POST Body: ?php phpinfo(); ?防御措施永远关闭allow_url_include。这是铁律。4.4 场景四信息泄露与错误处理php://filter不仅可以用于包含还可以用于触发错误有时错误信息会泄露部分文件内容或路径信息辅助攻击。攻击路径尝试包含一个不存在的过滤器或者构造畸形的过滤器链观察PHP返回的错误信息。防御措施在生产环境设置display_errors Off和log_errors On将错误记录到日志文件而非展示给用户。5. 安全开发最佳实践与配置加固了解了攻击方式我们可以系统地构建防御。5.1 PHP配置加固php.ini以下配置是底线; 禁止包含远程URL文件必须关闭 allow_url_include Off ; 虽然伪协议不受此影响但关闭它可防御http://等协议的攻击 allow_url_fopen Off ; 根据实际需求如果不需要从网络读文件建议关闭 ; 关闭危险函数 disable_functions eval, system, exec, shell_exec, passthru, proc_open, popen, parse_ini_file, show_source, highlight_file, dl, ... ; 限制文件系统访问范围 open_basedir /var/www/html/your_project:/tmp ; 根据实际情况设置多个目录用冒号分隔 ; 错误处理生产环境不显示错误 display_errors Off log_errors On error_log /var/log/php_errors.log ; 限制POST数据大小防止php://input被用于DoS post_max_size 10M ; 根据业务需要调整 ; 启用严格模式 expose_php Off ; 隐藏PHP版本信息5.2 安全的代码编写习惯永远不要信任用户输入对所有来自$_GET、$_POST、$_REQUEST、$_COOKIE、$_SERVER中某些字段如PATH_INFO的数据进行过滤和验证。使用白名单而非黑名单对于文件包含、文件操作等定义明确的、有限的允许列表。// 错误做法黑名单 $page $_GET[page]; if ($page ! badpage.php) { include($page); } // 正确做法白名单 $allowedPages [home, about, contact]; $page $_GET[page]; if (in_array($page, $allowedPages)) { include(./templates/ . $page . .php); } else { include(./templates/404.php); }使用安全的路径操作函数使用basename()去除路径中的目录部分防止目录遍历。使用realpath()结合open_basedir检查确保路径在允许范围内。文件上传安全检查MIME类型$_FILES[‘file’][‘type’]不可信需用finfo_file()。检查文件头魔术数字。重命名文件使用随机字符串。设置正确的文件权限如0644。将上传目录设置为不可执行。5.3 定期安全审计与依赖检查代码审计使用静态分析工具如phpcs配合安全标准phpstanpsalm或商业SAST工具扫描代码中的危险函数调用和用户输入流。依赖检查使用composer audit或OWASP Dependency-Check定期检查项目依赖的第三方库是否存在已知漏洞。服务器日志分析定期检查Web服务器访问日志和PHP错误日志寻找可疑的请求模式如大量尝试访问php://filter、/etc/passwd、config.php的请求。6. 高级技巧与边界案例探讨6.1 过滤器链的嵌套与复杂利用过滤器可以嵌套使用实现复杂的数据转换。这在某些CTFCapture The Flag竞赛或深度渗透测试中会出现。php://filter/readstring.toupper|string.rot13|convert.base64-encode/resourceflag.php这个链会先将flag.php内容转为大写然后做ROT13编码最后进行Base64编码输出。攻击者需要逆向这个过程才能得到原始信息。防御方需要意识到任何用户可控的过滤器参数都可能被用来构造复杂的攻击载荷。6.2 php://fd 协议php://fd允许直接访问文件描述符。例如php://fd/0是标准输入STDINphp://fd/1是标准输出STDOUT。这个协议在CLI脚本中更有用在Web环境下使用场景较少且直接操作文件描述符风险极高通常应避免。6.3 自定义流包装器PHP允许开发者注册自定义的流包装器。这提供了巨大的灵活性例如可以创建一个db://协议来像操作文件一样操作数据库中的BLOB字段。然而如果注册自定义包装器的代码存在缺陷如允许用户控制协议名也可能引入新的攻击面。stream_wrapper_register(myprotocol, MyProtocolWrapper); // 如果用户能控制 $userInput, 且 MyProtocolWrapper 实现不安全... file_get_contents($userInput);安全建议谨慎实现自定义包装器确保其内部逻辑安全并对传入的路径进行严格校验。6.4 与PHP版本相关的行为差异不同PHP版本对伪协议的支持和行为可能有细微差别。例如某些过滤器在特定版本才被引入或者某些安全限制在后续版本中被加强。PHP 5.xallow_url_include默认可能为Off但管理员的错误配置更常见。PHP 7.0移除了一些旧的特性如$HTTP_RAW_POST_DATA对某些错误处理更加严格。PHP 8.0持续加强安全性和类型系统。在编写兼容性代码或进行渗透测试时需要关注目标环境的PHP版本。一个常见的版本相关问题是php://filter与include/require的行为。在某些早期版本或特定配置下即使包含的文件内容被Base64编码如果编码后的字符串恰好构成了有效的PHP代码片段也可能导致意外执行。因此依赖“编码后就不会执行”的想法是不完全可靠的根本之道还是杜绝用户输入直接进入包含函数。7. 实战演练构建一个安全的文件查看器理论说再多不如动手实践。假设我们需要开发一个后台功能允许管理员查看指定日志文件的内容例如/var/log/app/error.log但不能执行任何代码。不安全版本绝对禁止// unsafe_viewer.php $file $_GET[file]; // 用户直接传入文件路径 highlight_file($file); // 高危直接包含用户输入安全版本实现// safe_log_viewer.php ?php // 1. 身份验证和授权 (此处省略实际必须有) // session_start(); if (!isAdmin()) { die(Forbidden); } // 2. 定义严格的白名单 $allowedLogs [ error /var/log/app/error.log, access /var/log/app/access.log, debug /var/log/app/debug.log, ]; // 3. 获取用户选择默认为error日志 $logKey $_GET[log] ?? error; // 4. 白名单校验 if (!array_key_exists($logKey, $allowedLogs)) { die(Invalid log type specified.); } $logFile $allowedLogs[$logKey]; // 5. 二次路径安全校验 (防御目录遍历等) $realPath realpath($logFile); if ($realPath false || strpos($realPath, /var/log/app/) ! 0) { // 文件不存在或路径不在允许的目录内 die(Log file not found or access denied.); } // 6. 安全地读取和显示内容 // 使用 htmlspecialchars 转义所有输出防止XSS echo pre; echo htmlspecialchars(file_get_contents($realPath), ENT_QUOTES, UTF-8); echo /pre; // 或者使用 readfile 并确保内容类型为纯文本但需注意大文件内存问题 // header(Content-Type: text/plain; charsetutf-8); // readfile($realPath); ?这个安全版本的核心在于白名单用户只能通过log参数选择预定义的键而不是传递任意路径。路径固定真实的文件路径在代码中写死与用户输入无关。二次校验使用realpath()解析真实路径并检查其前缀是否在允许的目录下。输出转义使用htmlspecialchars()防止日志内容本身包含HTML/JS代码导致XSS。完全避免了include、require和动态文件路径拼接从根本上杜绝了文件包含漏洞。通过这个例子你可以清晰地看到安全的代码不是添加一两个函数而是从设计上就堵死所有不可控的输入点。伪协议的知识让你能理解攻击者会从哪些角度思考从而在设计和编码阶段就做出更周全的防御。我个人在多年的开发和安全评估中一个最深的体会是安全是一个整体链条任何一个环节的疏忽都可能导致前功尽弃。理解像PHP伪协议这样的底层特性不是为了炫技而是为了在代码中构建起更精准、更坚固的防线。下次当你写下file_get_contents或include时不妨多花几秒钟思考一下这个参数我真的完全控制了吗