下面我们来分析一下DVWA中文件包含漏洞的源码。
首先文件包含的主页面是D:\AppServ\www\dvwa\vulnerabilities\fi\index.php文件，文件中的主要代码部分：
在这段代码中，首先使用switch语句根据用户选择的安全级别，分别将low.php、medium.php、high.php赋值给变量$vulnerabilityFile，接下来使用require_once函数来包含用户所选择的页面，最后用include函数来包含变量$file。
变量$file正是来自于low.php、medium.php、high.php。
在low.php中，以GET方式获取用户通过page参数传来的数据，并赋值给变量$file，可以看到这里对page参数没有进行任何的过滤处理。
在medium.php中，通过str_replace()函数将用户传来的数据进行了替换，主要是将http://和https://都替换成了空，这里主要是为了防止远程文件包含。
我们之前所使用的文件包含都是包含目标服务器上的本地文件，因而称为本地文件包含LFI，其实也可以包含远程服务器上的文件，比如http://127.0.0.1/dvwa/vulnerabilities/fi/?page=php://192.168.80.132/info.php，这称为远程文件包含RFI。很明显RFI的威力更强，但要能实施RFI的前提是要保证PHP中的两项参数allow_url_fopen和 allow_url_include处于开启状态，这两项参数默认状态下都是关闭的，因而RFI多半是执行不了。据说可以通过“zlib://”和“ogg://”等方式绕过，但是我目前还没有查找到相关资料，也没有验证，这个问题就暂且搁置吧。
总之，medium对LFI没有任何的影响，因而之前所使用的文件包含操作都可以执行。
最后看下high.php，这里用if语句来判断用户输入的数据是否是inlude.php，如果不是则直接报错退出，其实也就是指定了只允许包含include.php文件。这是最为安全的一种防御措施，当然实践中可能会有多个文件需要用户来选择，那么也只需要多进行几次判断即可。经过这样的设计，也就不存在文件包含漏洞了。
文件包含漏洞挖掘的思路跟之前一样，仍是搜索include()、include_once()、require()和require_once()这些函数，并且观察这些函数所包含的内容是否可以由用户控制，并是否采取了防御措施。
比如在下面这段代码中，include_once()函数中包含了变量$lang，而这个变量可以由用户输入且没有经过任何的处理，因而这里就产生了文件包含漏洞。
