1. 项目概述为什么从CTF靶场学漏洞更有效很多刚入门安全的朋友一听到“文件包含漏洞”或者“LFI”第一反应可能就是去翻看那些厚重的安全教材或者看一些概念性的文章。但说实话光看理论不亲手“摸”一下你很难真正理解攻击者是怎么想的防御又该从何做起。这也是为什么我特别推荐通过像BUUCTF这样的在线靶场来学习。BUUCTF平台上的题目尤其是Basic系列就像是给你设计好的一整套“从入门到精通”的实验环境。它把现实中可能非常复杂的漏洞场景抽象成一个又一个具体、可操作的目标让你在解题的过程中被迫去思考、去尝试、去犯错最后才能真正掌握。文件包含漏洞特别是本地文件包含Local File Inclusion, LFI是Web安全中一个经典且危害巨大的漏洞类型。它允许攻击者通过Web应用的动态文件包含功能去读取或执行服务器本地的敏感文件。听起来简单但它的利用方式却非常灵活从简单的读取/etc/passwd到结合其他漏洞实现远程代码执行RCE其危害可以呈指数级放大。通过解BUUCTF的相关题目你不仅能学会那几种经典的“姿势”更能理解每一种姿势背后的原理和适用场景从而在未来的渗透测试或代码审计中形成条件反射般的漏洞挖掘思路。这篇文章我就以一名多年渗透测试员的视角带你一起“盘一盘”BUUCTF中关于LFI漏洞的典型题目。我们不止步于写出答案更要深挖每一步操作背后的逻辑并最终归纳出真正有效的防御方案。无论你是正在打CTF的新手还是希望巩固Web安全基础的开发者相信这篇结合了实战靶场的深度解析都能让你有所收获。2. 文件包含漏洞核心原理与BUUCTF环境搭建2.1 漏洞产生的根本原因动态包含的信任危机要理解文件包含漏洞首先得明白程序开发者当初为什么要用“文件包含”这个功能。想象一下你正在开发一个网站这个网站有头部header、尾部footer、侧边栏sidebar和主要内容区。如果每个页面都把这些部分的HTML代码写一遍那将是巨大的重复劳动而且一旦要修改样式就得改无数个文件。于是聪明的开发者会把这些公共部分写成独立的文件比如header.php,footer.php然后在每个页面里用一句include(‘header.php’)这样的语句把它们“包含”进来。这样修改只需动一个文件所有页面都会同步更新这就是文件包含的初衷——提高代码复用性和可维护性。PHP中常用的包含函数有四个include(),require(),include_once(),require_once()。它们的区别主要在于处理包含失败时的行为require会报致命错误并停止include只会报警告以及是否重复包含。但就漏洞而言它们四兄弟的“危险性”是一样的。漏洞产生的关键就在于这个“包含”的动作是动态的。也就是说包含哪个文件是由一个变量参数来控制的。通常这个参数来自于用户输入比如URL中的?page参数。一段有问题的代码可能长这样// file: index.php $page $_GET[‘page’]; include($page . ‘.php’);开发者的本意可能是用户访问index.php?pagehome我就包含home.php访问index.php?pageabout我就包含about.php。看起来没问题对吧但问题就出在开发者完全信任了用户的输入没有对$page这个变量进行任何有效的过滤和校验。攻击者这时就可以为所欲为我不传home或about了我传一个../../../../etc/passwd试试于是代码就变成了include(‘../../../../etc/passwd’ . ‘.php’)。虽然拼接了.php但通过目录遍历../攻击者已经跳出了Web应用的目录试图去包含系统敏感文件。如果服务器配置不当比如open_basedir限制不严或者存在某些特殊技巧我们后面会讲攻击就可能成功。这就是本地文件包含LFI最基础的原理程序未对用户控制的包含路径进行过滤导致可以包含预期之外的本机文件。2.2 BUUCTF靶场环境与题目特点解析BUUCTF是一个非常好的国内CTF在线练习平台它的Web题目尤其是Basic系列对于新手理解基础漏洞模型非常友好。这些题目通常有几个特点环境纯净且聚焦一道题通常只考察一个或少数几个核心知识点不会用复杂的业务逻辑干扰你。比如LFI的题目它的页面功能可能极其简单就是一个文件包含点让你心无旁骛地研究这个漏洞。漏洞点明显为了教学目的漏洞点往往设置得比较“裸露”参数名可能就是file、page、include这种一眼就能看出来可能存在文件包含。这降低了入门门槛让你能快速进入漏洞利用的环节。存在“标准答案”但鼓励多种解法题目设计时通常预设了通关的“预期解”但由于漏洞本身的特性有经验的选手往往能想出更多“非预期解”。这能极大地锻炼你的发散思维。与真实场景有结合虽然简化了但题目的漏洞代码片段很多都源于真实CMS或框架的简化版你在这里学到的技巧稍加变通就能应用到实际渗透测试中。在开始实战前我强烈建议你在自己的实验环境比如用Docker快速搭建一个PHPApache的环境里按照题目给出的源码亲手部署一下漏洞环境。这个过程能让你更深刻地理解漏洞上下文并且可以放心大胆地进行各种破坏性测试而不用担心影响他人。记住在CTF或自家实验环境里“搞破坏”是学习安全最有效的方式之一。3. LFI漏洞的三种核心利用姿势深度剖析掌握了基本原理我们就可以进入最激动人心的环节——利用。很多人学漏洞只记payload不问为什么这样永远只能停留在“脚本小子”的阶段。下面我将结合BUUCTF题目中常见的场景详细拆解三种最核心的LFI利用姿势并告诉你每一种的底层逻辑和限制条件。3.1 姿势一目录遍历与敏感文件读取这是最直接、最经典的利用方式也是判断一个文件包含点是否存在的“敲门砖”。利用场景当包含参数几乎无过滤或者仅做了简单的后缀拼接如.php且服务器权限设置宽松时。典型Payload与原理../../../../etc/passwd经典中的经典。目的是读取Linux系统的用户账户信息。/etc/passwd文件全局可读是验证LFI是否存在最常用的“测试文件”。这里的../每出现一次就向上一层目录。你需要多少个../取决于Web应用根目录到目标文件的相对深度。这需要一点猜测和尝试。../../../../etc/shadow尝试读取加密后的用户密码哈希。但这个文件通常只有root可读成功率远低于passwd。../../../../windows/win.ini或../../../../windows/system32/drivers/etc/hosts在Windows服务器上的对应测试文件。file:///etc/passwd使用PHP的file://协议封装器直接读取绝对路径文件。这在某些限制了../但未过滤协议的场景下有效。日志文件路径例如/var/log/apache2/access.log。这是后续进行“日志投毒”攻击的关键第一步你需要先找到日志文件的准确位置。BUUCTF实战联想在题目中你可能会遇到一个包含点直接尝试?file../../../../etc/passwd发现返回了乱码或者被拦截。这时不要轻易放弃可以尝试以下技巧URL编码将../编码为%2e%2e%2f或双重编码%252e%252e%252f可能绕过简单的字符串过滤。超长目录遍历有时候路径深度很难猜可以简单粗暴地写上一长串../比如../../../../../../../etc/passwd。尝试读取Web目录下的源码如果读不了系统文件可以尝试包含网站自身的配置文件比如./config.php、../index.php等也许能发现数据库密码等敏感信息这就是所谓的“源码泄露”。注意在实际渗透测试中读取/etc/passwd除了证明漏洞存在更重要的是获取系统上的有效用户名列表为后续的密码爆破或SSH爆破提供字典。3.2 姿势二利用PHP封装协议进行信息收集与绕过当直接的路径遍历被过滤时PHP内置的各种“封装协议”Wrapper就成了我们的神兵利器。它们像是给include()或file_get_contents()这类文件系统函数加装的“插件”让它们不仅能读文件还能处理数据流。核心协议详解php://filter—— 读取源码的利器这是LFI利用中最常用、最重要的协议。它的核心作用是对数据流进行“过滤”读写时进行编码转换。利用链php://filter/readconvert.base64-encode/resource目标文件原理include()函数在执行时会试图将包含的文件内容作为PHP代码来解析。如果直接包含一个.php源码文件我们看到的是执行后的结果通常是空白或HTML而非源码本身。php://filter的convert.base64-encode过滤器会在文件内容被include()“执行”之前先将其进行Base64编码。Base64编码后的文本不再是有效的PHP代码因此include()不会执行它而是直接将编码后的文本输出到页面。我们拿到这段Base64字符串解码后就能得到原始的PHP源代码。BUUCTF应用题目中经常让你去读取一个flag.php或者index.php的源码。直接包含flag.php是看不到flag的因为里面的$flag变量被PHP执行了而输出逻辑可能被隐藏。这时就必须用?filephp://filter/readconvert.base64-encode/resourceflag.php拿到Base64密文解码即得flag。php://input与data://—— 执行代码的桥梁这两个协议是LFI通向远程代码执行RCE的关键跳板但前提是allow_url_include这个PHP配置项必须为On默认是Off因此实战中较少见但CTF中常开启。php://input可以访问请求的原始数据即HTTP POST请求的Body部分。利用方法?filephp://input同时用POST方法发送?php system(‘whoami’);?。原理include()包含了php://input这个“流”而这个流的内容就是我们POST过去的PHP代码于是代码就被执行了。data://直接将数据内嵌在URI中进行包含。利用方法?filedata://text/plain,?php phpinfo();?或?filedata://text/plain;base64,PD9waHAgcGhwaW5mbygpOz8Base64编码版。原理直接将一段文本或Base64编码后的文本作为“文件”内容提供给include()函数。实操心得在测试php://input时务必使用Burp Suite、Postman等工具发送POST请求浏览器地址栏的GET请求是无法携带POST Body的。另外注意请求头Content-Type有时需要设置为application/x-www-form-urlencoded。3.3 姿势三日志注入与条件竞争组合拳这是LFI利用中技术含量较高的一种它利用了“几乎所有Web请求都会被记录”这一特性将LFI与其他漏洞利用条件相结合。利用场景当目标存在LFI但无法使用php://input和data://allow_url_includeOff并且我们也找不到其他可上传恶意代码的文件时。核心步骤定位日志文件首先利用姿势一中的目录遍历找到Web服务器的访问日志文件。常见路径有Apache:/var/log/apache2/access.log,/var/log/httpd/access_logNginx:/var/log/nginx/access.log通过LFI包含这个日志文件确认我们可以读取它。污染日志我们的目标是让一句PHP代码被写入这个日志文件。由于日志文件记录的是HTTP请求我们只需要在User-Agent、Referer或请求路径URL中插入PHP代码这个请求被记录时代码就会被写入日志。例如使用curl或Burp Suite发送一个请求其中User-Agent设置为?php system($_GET[‘c’]); ?。原理User-Agent是HTTP请求头的一部分会被原样记录到access.log中。于是日志文件的某一行里就包含了一段可执行的PHP代码。包含日志执行代码通过LFI漏洞去包含这个已经被我们“投毒”的访问日志文件。当include()函数读取并执行日志文件时我们写入的那行“日志记录”即我们的PHP代码就会被当作PHP代码执行。此时我们就可以通过传递参数来执行命令了例如?file/var/log/nginx/access.logcwhoami。条件竞争的妙用在一些更复杂的场景下日志文件可能非常大包含整个文件会导致超时或内存不足。或者我们插入的代码行可能因为日志滚动log rotation或格式问题导致包含失败。这时可以结合条件竞争快速、连续地发起大量包含日志的请求同时另一个线程不断发送带有恶意代码的请求去污染日志从而提高代码被成功执行的几率。BUUCTF实战联想我印象中有一道题就是典型的日志文件包含。题目给了LFI点但过滤了php://和data://也读不到其他有用的文件。唯一的出路就是去猜日志路径。通过尝试常见的日志位置最终在/var/log/nginx/access.log中找到了突破口。在User-Agent里写入一句话木马再通过LFI包含轻松拿到了shell。这道题完美地诠释了“利用一切可利用的资源”这一渗透测试核心思想。4. 从攻击到防御构建文件包含漏洞的立体防护网学攻击是为了更好地防御。了解了攻击者的所有伎俩我们就能站在更高的维度上设计防护策略。防御LFI漏洞绝不仅仅是加一个过滤函数那么简单它需要从开发到运维的全流程关注。4.1 代码层防御白名单与硬编码是王道所有安全防御的起点都应该是代码本身。对于文件包含最有效、最根本的防御措施就是避免使用用户输入动态控制包含路径。使用白名单机制如果业务上确实需要动态包含那么必须采用白名单。$allowed_pages [‘home’, ‘about’, ‘contact’]; $page $_GET[‘page’]; if (in_array($page, $allowed_pages)) { include($page . ‘.php’); } else { include(‘error.php’); // 或直接die(‘Invalid page!’); }只允许包含预定义好的、安全的文件。这是最推荐的做法。硬编码或映射更进一步可以完全不用用户输入而是通过路由参数映射到固定的文件。// 使用路由例如 /index.php/home $route explode(‘/’, $_SERVER[‘REQUEST_URI’]); $action $route[2] ?? ‘home’; // 获取第三个部分 $pageMap [‘home’ ‘home.php’, ‘about’ ‘about.php’]; $file $pageMap[$action] ?? ‘error.php’; include($file);严格过滤与校验如果白名单实在难以实现在一些老旧或复杂系统中则必须进行严格的过滤。剥离目录遍历字符str_replace(‘../’, ‘’, $input)。但要注意双写等绕过….//。检查最终路径使用realpath()函数获取文件的绝对路径然后检查这个绝对路径是否在允许的Web目录内。$base_dir ‘/var/www/html/’; $user_path $_GET[‘file’]; $real_path realpath($base_dir . $user_path); if ($real_path false || strpos($real_path, $base_dir) ! 0) { // 路径不存在或不在基础目录内拒绝 die(‘Access denied.’); } include($real_path);4.2 配置层加固给PHP套上“紧箍咒”安全的代码需要运行在安全的环境上。PHP的配置能从根本上限制一些高危操作。关闭危险特性在php.ini中进行如下设置allow_url_fopen Off禁止通过URL打开文件。allow_url_include Off务必关闭这是阻止php://input和data://协议导致RCE的最关键配置。在绝大多数生产环境中没有任何理由需要开启它。open_basedir /var/www/html将PHP可访问的文件限制在指定的目录树内。这是防止目录遍历读取系统文件的重要防线。但要注意open_basedir可以被某些方式绕过不能作为唯一依赖。使用disable_functions在php.ini中禁用不必要的危险函数。disable_functions exec,passthru,shell_exec,system,proc_open,popen,…这样即使攻击者通过LFI实现了代码执行也无法调用这些函数来执行系统命令极大地增加了攻击难度。4.3 运维与架构层最小权限与纵深防御防御不能只靠应用本身系统和架构层面的措施同样重要。Web服务器运行在低权限账户下不要用root或www-data如果它权限过高来运行Nginx/Apache进程。创建一个专用的、权限最低的用户来运行Web服务。这样即使被攻破攻击者能做的事情也非常有限。严格控制文件系统权限遵循最小权限原则。Web目录只给Web用户读和执行权限必要时给写权限如上传目录且上传目录要禁止脚本执行。系统敏感文件如/etc/passwd, 日志目录要确保Web用户无权读取。日志文件单独存放并严格权限控制将Web日志存放在Web用户不可读的目录或者至少确保日志文件权限为640所有者可读写组用户可读其他用户无权限。这能有效防御日志文件包含攻击。部署Web应用防火墙WAF在应用前端部署WAF可以拦截常见的目录遍历、协议封装等攻击payload为应用增加一层缓冲。定期安全审计与更新对代码进行定期的安全审计特别是涉及文件操作、包含、上传的功能点。同时保持PHP、Web服务器及所有依赖库的最新版本及时修补已知漏洞。5. 实战中常见问题与高级绕过技巧实录在实际的CTF比赛或渗透测试中你很少会遇到一个“标准”的、毫无过滤的LFI点。防守方总会设置各种障碍。下面记录一些我遇到过的“坑”以及对应的思考与绕过技巧。5.1 过滤了../怎么办这是最常见的过滤。简单的字符串替换str_replace(‘../’, ‘’, $input)很容易被双写绕过….//。经过一次替换后中间的../被删除剩下的../又组合在了一起。Payload….//….//….//etc/passwd。更聪明的过滤可能会用正则表达式彻底删除所有../的组合。这时可以尝试绝对路径如果知道Web目录的绝对路径可以直接尝试/var/www/html/../../../etc/passwd。有时候过滤逻辑有缺陷可能只检查了开头是否有../。URL编码/双重编码%2e%2e%2f或%252e%252e%252f。非标准路径表示在Windows环境下可以尝试..\反斜杠或者..//混合。在Linux下..两个点和/之间是否可以插入控制字符或大量空格通常不行但可以测试边界情况。5.2 强制添加了后缀如.php怎么办很多开发者认为只要我强制加上.php后缀你就只能包含PHP文件了。破解方法有很多利用%00空字节截断PHP 5.3.4这是历史漏洞但在一些老系统或特定CTF环境中可能遇到。Payload../../../../etc/passwd%00。原理是在C语言中空字节\0是字符串的结束符。PHP底层用C实现早期版本在拼接后缀前如果路径中包含%00会错误地将其视为字符串结束从而忽略后面的.php。注意这个漏洞需要magic_quotes_gpcOff且PHP版本较低。利用路径长度截断在非常老的系统上PHP 5.1.x之前超长的文件名可能会被截断。但此法现代几乎无效。利用?或#在URL中?之后是查询参数#之后是锚点。有时include()函数在加载文件时会忽略这些符号之后的内容。Payload../../../../etc/passwd?.php或../../../../etc/passwd%23.php#需要编码为%23。这样实际尝试包含的文件可能是../../../../etc/passwd?而.php被当作查询参数忽略了。这种方法高度依赖于服务器和PHP的具体实现不是总有效但值得一试。利用php://filter这是对付后缀限制的终极武器。因为php://filter/readconvert.base64-encode/resourceetc/passwd本身就是一个完整的“文件名”其后不需要也不应该有后缀。即使代码在后面拼接了.php变成了php://filter/.../resourceetc/passwd.php只要resource参数指定的文件存在过滤器协议依然会工作。它关注的是resource后面的路径。5.3 找不到日志文件或者日志不可读怎么办日志包含是条好路但前提是能找到且能读。多路径尝试除了常见的/var/log/nginx/还可以试试/usr/local/nginx/logs/、/proc/self/fd/有时会包含进程打开的文件描述符可能指向日志等。读取其他应用日志考虑SSH日志/var/log/auth.log、邮件日志/var/log/mail.log。如果你能通过Web应用执行命令比如通过另一个漏洞可以先执行ps aux | grep log或find / -name “*.log” 2/dev/null来寻找。利用/proc文件系统Linux的/proc是个信息宝库。/proc/self/environ包含了当前进程的环境变量其中可能有USER、PATH甚至有时会有HTTP_USER_AGENT如果PHP以CGI模式运行。你可以污染User-Agent然后包含这个文件来执行代码。/proc/self/fd/目录下可能有指向访问日志的文件描述符符号链接。转向其他临时文件或会话文件思路是“让服务器自己生成一个包含我们代码的文件”。除了日志还可以考虑PHP Session文件如果应用使用了Session并且我们能控制部分Session数据比如一个名为PHPSESSID的Cookie对应的值我们可以通过LFI包含Session文件通常位于/tmp/sess_[PHPSESSID]来执行代码。上传临时文件如果存在文件上传功能即使上传点有严格校验文件在传输过程中可能会在/tmp目录下产生临时文件。通过条件竞争在临时文件被删除前包含它也可能成功。但这需要极快的速度和一点运气。5.4 如何判断allow_url_include是否开启在无法查看phpinfo()的情况下可以通过一些技巧判断尝试使用php://input如果返回错误信息中提及allow_url_include被禁用或者请求直接无任何反应与包含一个不存在的文件行为不同则可能是关闭的。尝试包含一个已知存在的本地文件再尝试包含一个不存在的http://远程URL。观察两者错误信息的差异。但这种方法不一定准确。最可靠的方式还是通过其他信息泄露漏洞如目录遍历读取php.ini或通过报错信息来确认。6. 总结与个人实战心得文件包含漏洞的学习路径在我看来是一个典型的“从点到面再从面到体”的过程。BUUCTF的Basic题目就是这个“点”它给你一个最纯净的漏洞模型。你通过解题掌握了../、php://filter、日志包含这些基本的“姿势”。这是第一步。第二步是“到面”。你需要理解这些姿势不是孤立的。php://filter为什么能读源码是因为Base64编码避免了PHP解析。日志包含为什么能执行代码是因为服务器把我们的HTTP请求原样记录成了文件。这背后是PHP封装协议、Web服务器日志机制、文件系统权限等多个知识面的交叉。当你理解了这些你就不会再死记硬背payload而是能根据现场情况自己组合、创造出新的利用方法。第三步是“到体”。当你站在防御者的角度回头看你会发现一个简单的LFI漏洞其防御涉及安全开发规范白名单、服务器安全配置php.ini、操作系统权限管理、甚至是WAF规则编写。这时你不仅是一个会攻击的黑客更是一个能系统性评估和提升安全架构的工程师。在我自己打CTF和做渗透测试的经历中对于LFI漏洞我养成了这样的排查习惯确认漏洞存在先用../../../../etc/passwd或php://filter/resource/etc/passwd简单测试。探测过滤规则如果失败分别测试包含../、php://、http://等看返回什么错误初步判断过滤了哪些关键词或协议。尝试读取源码无论有没有过滤都试试php://filter读一下index.php本身和可能的配置文件源码里往往藏着其他漏洞线索或数据库密码。寻找辅助突破口检查是否有文件上传点、是否有其他参数可能污染日志或Session、查看报错信息泄露的路径。组合利用将LFI与找到的其他弱点如简单的上传、SSRF等结合往往能打开新局面。最后记住一句话所有的漏洞利用本质都是对程序预期行为的一种“扭曲”或“滥用”。文件包含漏洞就是程序预期包含可控的模板文件却被我们扭曲成了包含系统密码文件或可执行代码流。理解了程序的“预期”你就能更精准地找到“扭曲”它的方法。而作为开发者时刻对用户输入保持“零信任”严格遵循最小权限原则则是构建安全软件的不二法门。希望这篇从BUUCTF靶场出发的深度解析能帮你不仅拿下题目更建立起一套关于文件包含漏洞的立体攻防知识体系。
从BUUCTF靶场实战剖析文件包含漏洞：原理、利用与防御
1. 项目概述为什么从CTF靶场学漏洞更有效很多刚入门安全的朋友一听到“文件包含漏洞”或者“LFI”第一反应可能就是去翻看那些厚重的安全教材或者看一些概念性的文章。但说实话光看理论不亲手“摸”一下你很难真正理解攻击者是怎么想的防御又该从何做起。这也是为什么我特别推荐通过像BUUCTF这样的在线靶场来学习。BUUCTF平台上的题目尤其是Basic系列就像是给你设计好的一整套“从入门到精通”的实验环境。它把现实中可能非常复杂的漏洞场景抽象成一个又一个具体、可操作的目标让你在解题的过程中被迫去思考、去尝试、去犯错最后才能真正掌握。文件包含漏洞特别是本地文件包含Local File Inclusion, LFI是Web安全中一个经典且危害巨大的漏洞类型。它允许攻击者通过Web应用的动态文件包含功能去读取或执行服务器本地的敏感文件。听起来简单但它的利用方式却非常灵活从简单的读取/etc/passwd到结合其他漏洞实现远程代码执行RCE其危害可以呈指数级放大。通过解BUUCTF的相关题目你不仅能学会那几种经典的“姿势”更能理解每一种姿势背后的原理和适用场景从而在未来的渗透测试或代码审计中形成条件反射般的漏洞挖掘思路。这篇文章我就以一名多年渗透测试员的视角带你一起“盘一盘”BUUCTF中关于LFI漏洞的典型题目。我们不止步于写出答案更要深挖每一步操作背后的逻辑并最终归纳出真正有效的防御方案。无论你是正在打CTF的新手还是希望巩固Web安全基础的开发者相信这篇结合了实战靶场的深度解析都能让你有所收获。2. 文件包含漏洞核心原理与BUUCTF环境搭建2.1 漏洞产生的根本原因动态包含的信任危机要理解文件包含漏洞首先得明白程序开发者当初为什么要用“文件包含”这个功能。想象一下你正在开发一个网站这个网站有头部header、尾部footer、侧边栏sidebar和主要内容区。如果每个页面都把这些部分的HTML代码写一遍那将是巨大的重复劳动而且一旦要修改样式就得改无数个文件。于是聪明的开发者会把这些公共部分写成独立的文件比如header.php,footer.php然后在每个页面里用一句include(‘header.php’)这样的语句把它们“包含”进来。这样修改只需动一个文件所有页面都会同步更新这就是文件包含的初衷——提高代码复用性和可维护性。PHP中常用的包含函数有四个include(),require(),include_once(),require_once()。它们的区别主要在于处理包含失败时的行为require会报致命错误并停止include只会报警告以及是否重复包含。但就漏洞而言它们四兄弟的“危险性”是一样的。漏洞产生的关键就在于这个“包含”的动作是动态的。也就是说包含哪个文件是由一个变量参数来控制的。通常这个参数来自于用户输入比如URL中的?page参数。一段有问题的代码可能长这样// file: index.php $page $_GET[‘page’]; include($page . ‘.php’);开发者的本意可能是用户访问index.php?pagehome我就包含home.php访问index.php?pageabout我就包含about.php。看起来没问题对吧但问题就出在开发者完全信任了用户的输入没有对$page这个变量进行任何有效的过滤和校验。攻击者这时就可以为所欲为我不传home或about了我传一个../../../../etc/passwd试试于是代码就变成了include(‘../../../../etc/passwd’ . ‘.php’)。虽然拼接了.php但通过目录遍历../攻击者已经跳出了Web应用的目录试图去包含系统敏感文件。如果服务器配置不当比如open_basedir限制不严或者存在某些特殊技巧我们后面会讲攻击就可能成功。这就是本地文件包含LFI最基础的原理程序未对用户控制的包含路径进行过滤导致可以包含预期之外的本机文件。2.2 BUUCTF靶场环境与题目特点解析BUUCTF是一个非常好的国内CTF在线练习平台它的Web题目尤其是Basic系列对于新手理解基础漏洞模型非常友好。这些题目通常有几个特点环境纯净且聚焦一道题通常只考察一个或少数几个核心知识点不会用复杂的业务逻辑干扰你。比如LFI的题目它的页面功能可能极其简单就是一个文件包含点让你心无旁骛地研究这个漏洞。漏洞点明显为了教学目的漏洞点往往设置得比较“裸露”参数名可能就是file、page、include这种一眼就能看出来可能存在文件包含。这降低了入门门槛让你能快速进入漏洞利用的环节。存在“标准答案”但鼓励多种解法题目设计时通常预设了通关的“预期解”但由于漏洞本身的特性有经验的选手往往能想出更多“非预期解”。这能极大地锻炼你的发散思维。与真实场景有结合虽然简化了但题目的漏洞代码片段很多都源于真实CMS或框架的简化版你在这里学到的技巧稍加变通就能应用到实际渗透测试中。在开始实战前我强烈建议你在自己的实验环境比如用Docker快速搭建一个PHPApache的环境里按照题目给出的源码亲手部署一下漏洞环境。这个过程能让你更深刻地理解漏洞上下文并且可以放心大胆地进行各种破坏性测试而不用担心影响他人。记住在CTF或自家实验环境里“搞破坏”是学习安全最有效的方式之一。3. LFI漏洞的三种核心利用姿势深度剖析掌握了基本原理我们就可以进入最激动人心的环节——利用。很多人学漏洞只记payload不问为什么这样永远只能停留在“脚本小子”的阶段。下面我将结合BUUCTF题目中常见的场景详细拆解三种最核心的LFI利用姿势并告诉你每一种的底层逻辑和限制条件。3.1 姿势一目录遍历与敏感文件读取这是最直接、最经典的利用方式也是判断一个文件包含点是否存在的“敲门砖”。利用场景当包含参数几乎无过滤或者仅做了简单的后缀拼接如.php且服务器权限设置宽松时。典型Payload与原理../../../../etc/passwd经典中的经典。目的是读取Linux系统的用户账户信息。/etc/passwd文件全局可读是验证LFI是否存在最常用的“测试文件”。这里的../每出现一次就向上一层目录。你需要多少个../取决于Web应用根目录到目标文件的相对深度。这需要一点猜测和尝试。../../../../etc/shadow尝试读取加密后的用户密码哈希。但这个文件通常只有root可读成功率远低于passwd。../../../../windows/win.ini或../../../../windows/system32/drivers/etc/hosts在Windows服务器上的对应测试文件。file:///etc/passwd使用PHP的file://协议封装器直接读取绝对路径文件。这在某些限制了../但未过滤协议的场景下有效。日志文件路径例如/var/log/apache2/access.log。这是后续进行“日志投毒”攻击的关键第一步你需要先找到日志文件的准确位置。BUUCTF实战联想在题目中你可能会遇到一个包含点直接尝试?file../../../../etc/passwd发现返回了乱码或者被拦截。这时不要轻易放弃可以尝试以下技巧URL编码将../编码为%2e%2e%2f或双重编码%252e%252e%252f可能绕过简单的字符串过滤。超长目录遍历有时候路径深度很难猜可以简单粗暴地写上一长串../比如../../../../../../../etc/passwd。尝试读取Web目录下的源码如果读不了系统文件可以尝试包含网站自身的配置文件比如./config.php、../index.php等也许能发现数据库密码等敏感信息这就是所谓的“源码泄露”。注意在实际渗透测试中读取/etc/passwd除了证明漏洞存在更重要的是获取系统上的有效用户名列表为后续的密码爆破或SSH爆破提供字典。3.2 姿势二利用PHP封装协议进行信息收集与绕过当直接的路径遍历被过滤时PHP内置的各种“封装协议”Wrapper就成了我们的神兵利器。它们像是给include()或file_get_contents()这类文件系统函数加装的“插件”让它们不仅能读文件还能处理数据流。核心协议详解php://filter—— 读取源码的利器这是LFI利用中最常用、最重要的协议。它的核心作用是对数据流进行“过滤”读写时进行编码转换。利用链php://filter/readconvert.base64-encode/resource目标文件原理include()函数在执行时会试图将包含的文件内容作为PHP代码来解析。如果直接包含一个.php源码文件我们看到的是执行后的结果通常是空白或HTML而非源码本身。php://filter的convert.base64-encode过滤器会在文件内容被include()“执行”之前先将其进行Base64编码。Base64编码后的文本不再是有效的PHP代码因此include()不会执行它而是直接将编码后的文本输出到页面。我们拿到这段Base64字符串解码后就能得到原始的PHP源代码。BUUCTF应用题目中经常让你去读取一个flag.php或者index.php的源码。直接包含flag.php是看不到flag的因为里面的$flag变量被PHP执行了而输出逻辑可能被隐藏。这时就必须用?filephp://filter/readconvert.base64-encode/resourceflag.php拿到Base64密文解码即得flag。php://input与data://—— 执行代码的桥梁这两个协议是LFI通向远程代码执行RCE的关键跳板但前提是allow_url_include这个PHP配置项必须为On默认是Off因此实战中较少见但CTF中常开启。php://input可以访问请求的原始数据即HTTP POST请求的Body部分。利用方法?filephp://input同时用POST方法发送?php system(‘whoami’);?。原理include()包含了php://input这个“流”而这个流的内容就是我们POST过去的PHP代码于是代码就被执行了。data://直接将数据内嵌在URI中进行包含。利用方法?filedata://text/plain,?php phpinfo();?或?filedata://text/plain;base64,PD9waHAgcGhwaW5mbygpOz8Base64编码版。原理直接将一段文本或Base64编码后的文本作为“文件”内容提供给include()函数。实操心得在测试php://input时务必使用Burp Suite、Postman等工具发送POST请求浏览器地址栏的GET请求是无法携带POST Body的。另外注意请求头Content-Type有时需要设置为application/x-www-form-urlencoded。3.3 姿势三日志注入与条件竞争组合拳这是LFI利用中技术含量较高的一种它利用了“几乎所有Web请求都会被记录”这一特性将LFI与其他漏洞利用条件相结合。利用场景当目标存在LFI但无法使用php://input和data://allow_url_includeOff并且我们也找不到其他可上传恶意代码的文件时。核心步骤定位日志文件首先利用姿势一中的目录遍历找到Web服务器的访问日志文件。常见路径有Apache:/var/log/apache2/access.log,/var/log/httpd/access_logNginx:/var/log/nginx/access.log通过LFI包含这个日志文件确认我们可以读取它。污染日志我们的目标是让一句PHP代码被写入这个日志文件。由于日志文件记录的是HTTP请求我们只需要在User-Agent、Referer或请求路径URL中插入PHP代码这个请求被记录时代码就会被写入日志。例如使用curl或Burp Suite发送一个请求其中User-Agent设置为?php system($_GET[‘c’]); ?。原理User-Agent是HTTP请求头的一部分会被原样记录到access.log中。于是日志文件的某一行里就包含了一段可执行的PHP代码。包含日志执行代码通过LFI漏洞去包含这个已经被我们“投毒”的访问日志文件。当include()函数读取并执行日志文件时我们写入的那行“日志记录”即我们的PHP代码就会被当作PHP代码执行。此时我们就可以通过传递参数来执行命令了例如?file/var/log/nginx/access.logcwhoami。条件竞争的妙用在一些更复杂的场景下日志文件可能非常大包含整个文件会导致超时或内存不足。或者我们插入的代码行可能因为日志滚动log rotation或格式问题导致包含失败。这时可以结合条件竞争快速、连续地发起大量包含日志的请求同时另一个线程不断发送带有恶意代码的请求去污染日志从而提高代码被成功执行的几率。BUUCTF实战联想我印象中有一道题就是典型的日志文件包含。题目给了LFI点但过滤了php://和data://也读不到其他有用的文件。唯一的出路就是去猜日志路径。通过尝试常见的日志位置最终在/var/log/nginx/access.log中找到了突破口。在User-Agent里写入一句话木马再通过LFI包含轻松拿到了shell。这道题完美地诠释了“利用一切可利用的资源”这一渗透测试核心思想。4. 从攻击到防御构建文件包含漏洞的立体防护网学攻击是为了更好地防御。了解了攻击者的所有伎俩我们就能站在更高的维度上设计防护策略。防御LFI漏洞绝不仅仅是加一个过滤函数那么简单它需要从开发到运维的全流程关注。4.1 代码层防御白名单与硬编码是王道所有安全防御的起点都应该是代码本身。对于文件包含最有效、最根本的防御措施就是避免使用用户输入动态控制包含路径。使用白名单机制如果业务上确实需要动态包含那么必须采用白名单。$allowed_pages [‘home’, ‘about’, ‘contact’]; $page $_GET[‘page’]; if (in_array($page, $allowed_pages)) { include($page . ‘.php’); } else { include(‘error.php’); // 或直接die(‘Invalid page!’); }只允许包含预定义好的、安全的文件。这是最推荐的做法。硬编码或映射更进一步可以完全不用用户输入而是通过路由参数映射到固定的文件。// 使用路由例如 /index.php/home $route explode(‘/’, $_SERVER[‘REQUEST_URI’]); $action $route[2] ?? ‘home’; // 获取第三个部分 $pageMap [‘home’ ‘home.php’, ‘about’ ‘about.php’]; $file $pageMap[$action] ?? ‘error.php’; include($file);严格过滤与校验如果白名单实在难以实现在一些老旧或复杂系统中则必须进行严格的过滤。剥离目录遍历字符str_replace(‘../’, ‘’, $input)。但要注意双写等绕过….//。检查最终路径使用realpath()函数获取文件的绝对路径然后检查这个绝对路径是否在允许的Web目录内。$base_dir ‘/var/www/html/’; $user_path $_GET[‘file’]; $real_path realpath($base_dir . $user_path); if ($real_path false || strpos($real_path, $base_dir) ! 0) { // 路径不存在或不在基础目录内拒绝 die(‘Access denied.’); } include($real_path);4.2 配置层加固给PHP套上“紧箍咒”安全的代码需要运行在安全的环境上。PHP的配置能从根本上限制一些高危操作。关闭危险特性在php.ini中进行如下设置allow_url_fopen Off禁止通过URL打开文件。allow_url_include Off务必关闭这是阻止php://input和data://协议导致RCE的最关键配置。在绝大多数生产环境中没有任何理由需要开启它。open_basedir /var/www/html将PHP可访问的文件限制在指定的目录树内。这是防止目录遍历读取系统文件的重要防线。但要注意open_basedir可以被某些方式绕过不能作为唯一依赖。使用disable_functions在php.ini中禁用不必要的危险函数。disable_functions exec,passthru,shell_exec,system,proc_open,popen,…这样即使攻击者通过LFI实现了代码执行也无法调用这些函数来执行系统命令极大地增加了攻击难度。4.3 运维与架构层最小权限与纵深防御防御不能只靠应用本身系统和架构层面的措施同样重要。Web服务器运行在低权限账户下不要用root或www-data如果它权限过高来运行Nginx/Apache进程。创建一个专用的、权限最低的用户来运行Web服务。这样即使被攻破攻击者能做的事情也非常有限。严格控制文件系统权限遵循最小权限原则。Web目录只给Web用户读和执行权限必要时给写权限如上传目录且上传目录要禁止脚本执行。系统敏感文件如/etc/passwd, 日志目录要确保Web用户无权读取。日志文件单独存放并严格权限控制将Web日志存放在Web用户不可读的目录或者至少确保日志文件权限为640所有者可读写组用户可读其他用户无权限。这能有效防御日志文件包含攻击。部署Web应用防火墙WAF在应用前端部署WAF可以拦截常见的目录遍历、协议封装等攻击payload为应用增加一层缓冲。定期安全审计与更新对代码进行定期的安全审计特别是涉及文件操作、包含、上传的功能点。同时保持PHP、Web服务器及所有依赖库的最新版本及时修补已知漏洞。5. 实战中常见问题与高级绕过技巧实录在实际的CTF比赛或渗透测试中你很少会遇到一个“标准”的、毫无过滤的LFI点。防守方总会设置各种障碍。下面记录一些我遇到过的“坑”以及对应的思考与绕过技巧。5.1 过滤了../怎么办这是最常见的过滤。简单的字符串替换str_replace(‘../’, ‘’, $input)很容易被双写绕过….//。经过一次替换后中间的../被删除剩下的../又组合在了一起。Payload….//….//….//etc/passwd。更聪明的过滤可能会用正则表达式彻底删除所有../的组合。这时可以尝试绝对路径如果知道Web目录的绝对路径可以直接尝试/var/www/html/../../../etc/passwd。有时候过滤逻辑有缺陷可能只检查了开头是否有../。URL编码/双重编码%2e%2e%2f或%252e%252e%252f。非标准路径表示在Windows环境下可以尝试..\反斜杠或者..//混合。在Linux下..两个点和/之间是否可以插入控制字符或大量空格通常不行但可以测试边界情况。5.2 强制添加了后缀如.php怎么办很多开发者认为只要我强制加上.php后缀你就只能包含PHP文件了。破解方法有很多利用%00空字节截断PHP 5.3.4这是历史漏洞但在一些老系统或特定CTF环境中可能遇到。Payload../../../../etc/passwd%00。原理是在C语言中空字节\0是字符串的结束符。PHP底层用C实现早期版本在拼接后缀前如果路径中包含%00会错误地将其视为字符串结束从而忽略后面的.php。注意这个漏洞需要magic_quotes_gpcOff且PHP版本较低。利用路径长度截断在非常老的系统上PHP 5.1.x之前超长的文件名可能会被截断。但此法现代几乎无效。利用?或#在URL中?之后是查询参数#之后是锚点。有时include()函数在加载文件时会忽略这些符号之后的内容。Payload../../../../etc/passwd?.php或../../../../etc/passwd%23.php#需要编码为%23。这样实际尝试包含的文件可能是../../../../etc/passwd?而.php被当作查询参数忽略了。这种方法高度依赖于服务器和PHP的具体实现不是总有效但值得一试。利用php://filter这是对付后缀限制的终极武器。因为php://filter/readconvert.base64-encode/resourceetc/passwd本身就是一个完整的“文件名”其后不需要也不应该有后缀。即使代码在后面拼接了.php变成了php://filter/.../resourceetc/passwd.php只要resource参数指定的文件存在过滤器协议依然会工作。它关注的是resource后面的路径。5.3 找不到日志文件或者日志不可读怎么办日志包含是条好路但前提是能找到且能读。多路径尝试除了常见的/var/log/nginx/还可以试试/usr/local/nginx/logs/、/proc/self/fd/有时会包含进程打开的文件描述符可能指向日志等。读取其他应用日志考虑SSH日志/var/log/auth.log、邮件日志/var/log/mail.log。如果你能通过Web应用执行命令比如通过另一个漏洞可以先执行ps aux | grep log或find / -name “*.log” 2/dev/null来寻找。利用/proc文件系统Linux的/proc是个信息宝库。/proc/self/environ包含了当前进程的环境变量其中可能有USER、PATH甚至有时会有HTTP_USER_AGENT如果PHP以CGI模式运行。你可以污染User-Agent然后包含这个文件来执行代码。/proc/self/fd/目录下可能有指向访问日志的文件描述符符号链接。转向其他临时文件或会话文件思路是“让服务器自己生成一个包含我们代码的文件”。除了日志还可以考虑PHP Session文件如果应用使用了Session并且我们能控制部分Session数据比如一个名为PHPSESSID的Cookie对应的值我们可以通过LFI包含Session文件通常位于/tmp/sess_[PHPSESSID]来执行代码。上传临时文件如果存在文件上传功能即使上传点有严格校验文件在传输过程中可能会在/tmp目录下产生临时文件。通过条件竞争在临时文件被删除前包含它也可能成功。但这需要极快的速度和一点运气。5.4 如何判断allow_url_include是否开启在无法查看phpinfo()的情况下可以通过一些技巧判断尝试使用php://input如果返回错误信息中提及allow_url_include被禁用或者请求直接无任何反应与包含一个不存在的文件行为不同则可能是关闭的。尝试包含一个已知存在的本地文件再尝试包含一个不存在的http://远程URL。观察两者错误信息的差异。但这种方法不一定准确。最可靠的方式还是通过其他信息泄露漏洞如目录遍历读取php.ini或通过报错信息来确认。6. 总结与个人实战心得文件包含漏洞的学习路径在我看来是一个典型的“从点到面再从面到体”的过程。BUUCTF的Basic题目就是这个“点”它给你一个最纯净的漏洞模型。你通过解题掌握了../、php://filter、日志包含这些基本的“姿势”。这是第一步。第二步是“到面”。你需要理解这些姿势不是孤立的。php://filter为什么能读源码是因为Base64编码避免了PHP解析。日志包含为什么能执行代码是因为服务器把我们的HTTP请求原样记录成了文件。这背后是PHP封装协议、Web服务器日志机制、文件系统权限等多个知识面的交叉。当你理解了这些你就不会再死记硬背payload而是能根据现场情况自己组合、创造出新的利用方法。第三步是“到体”。当你站在防御者的角度回头看你会发现一个简单的LFI漏洞其防御涉及安全开发规范白名单、服务器安全配置php.ini、操作系统权限管理、甚至是WAF规则编写。这时你不仅是一个会攻击的黑客更是一个能系统性评估和提升安全架构的工程师。在我自己打CTF和做渗透测试的经历中对于LFI漏洞我养成了这样的排查习惯确认漏洞存在先用../../../../etc/passwd或php://filter/resource/etc/passwd简单测试。探测过滤规则如果失败分别测试包含../、php://、http://等看返回什么错误初步判断过滤了哪些关键词或协议。尝试读取源码无论有没有过滤都试试php://filter读一下index.php本身和可能的配置文件源码里往往藏着其他漏洞线索或数据库密码。寻找辅助突破口检查是否有文件上传点、是否有其他参数可能污染日志或Session、查看报错信息泄露的路径。组合利用将LFI与找到的其他弱点如简单的上传、SSRF等结合往往能打开新局面。最后记住一句话所有的漏洞利用本质都是对程序预期行为的一种“扭曲”或“滥用”。文件包含漏洞就是程序预期包含可控的模板文件却被我们扭曲成了包含系统密码文件或可执行代码流。理解了程序的“预期”你就能更精准地找到“扭曲”它的方法。而作为开发者时刻对用户输入保持“零信任”严格遵循最小权限原则则是构建安全软件的不二法门。希望这篇从BUUCTF靶场出发的深度解析能帮你不仅拿下题目更建立起一套关于文件包含漏洞的立体攻防知识体系。
