Pikachu-File Inclusion, Unsafe file download & Unsafe file upload

Pikachu-File Inclusion, Unsafe file download & Unsafe file upload

文件包含漏洞

File Inclusion(文件包含漏洞)概述 文件包含,是一個功能。在各類開發語言中都提供了內置的文件包含函數,其可使開發人員在一個代碼文件中直接包含(引入)另一個代碼文件。 好比 在PHP中,提供了:
include(),include_once()
require(),require_once()
這些文件包含函數,這些函數在代碼設計中被常用到。
大多數狀況下,文件包含函數中包含的代碼文件是固定的,所以也不會出現安全問題。 可是,有些時候,文件包含的代碼文件被寫成了一個變量,且這個變量能夠由前端用戶傳進來,這種狀況下,若是沒有作足夠的安全考慮,則可能會引起文件包含漏洞。 攻擊着會指定一個「意想不到」的文件讓包含函數去執行,從而形成惡意操做。 根據不一樣的配置環境,文件包含漏洞分爲以下兩種狀況:
1.本地文件包含漏洞:僅可以對服務器本地的文件進行包含,因爲服務器上的文件並非攻擊者所可以控制的,所以該狀況下,攻擊着更多的會包含一些 固定的系統配置文件,從而讀取系統敏感信息。不少時候本地文件包含漏洞會結合一些特殊的文件上傳漏洞,從而造成更大的威力。
2.遠程文件包含漏洞:可以經過url地址對遠程的文件進行包含,這意味着攻擊者能夠傳入任意的代碼,這種狀況沒啥好說的,準備掛彩。 所以,在web應用系統的功能設計上儘可能不要讓前端用戶直接傳變量給包含函數,若是非要這麼作,也必定要作嚴格的白名單策略進行過濾。                     php

一、File Inclusion(local)

 

 這個url有點東西哈前端

 

 猜想有文件包含漏洞,因而試一試看看web

 

 放一個馬在目錄裏面shell

 

 而後讀取康康:數據庫

 

 成功利用馬進入服務器後端後端

二、File Inclusion(remote)

 

 

 

 這個地方對filename傳參有了include的過濾,但可能存在ssrf漏洞。瀏覽器

http://xx.xx.xx.xx/pikachu/vul/fileinclude/fi_remote.php?filename=https://www.cnblogs.com/p201721420021/&submit=%E6%8F%90%E4%BA%A4%E6%9F%A5%E8%AF%A2安全

 

 

成功跳轉進我本身的博客中。服務器

不安全的文件下載

文件下載功能在不少web系統上都會出現,通常咱們當點擊下載連接,便會向後臺發送一個下載請求,通常這個請求會包含一個須要下載的文件名稱,後臺在收到請求後 會開始執行下載代碼,將該文件名對應的文件response給瀏覽器,從而完成下載。 若是後臺在收到請求的文件名後,將其直接拼進下載文件的路徑中而不對其進行安全判斷的話,則可能會引起不安全的文件下載漏洞。
此時若是 攻擊者提交的不是一個程序預期的的文件名,而是一個精心構造的路徑(好比../../../etc/passwd),則頗有可能會直接將該指定的文件下載下來。 從而致使後臺敏感信息(密碼文件、源代碼等)被下載。
因此,在設計文件下載功能時,若是下載的目標文件是由前端傳進來的,則必定要對傳進來的文件進行安全考慮。 切記:全部與前端交互的數據都是不安全的,不能掉以輕心!
                     

 

 三、unsafe filedownload

 

 

 要求是點擊圖片能夠下載函數

 那仍是科比吧連接以下:

http://192.168.1.108/pikachu/vul/unsafedownload/execdownload.php?filename=kb.png

既然能夠直接經過filename讀取文件,那就直接構造payload:

http://192.168.1.108/pikachu/vul/unsafedownload/execdownload.php?filename=../../../shengcheng.txt

 

讀取網站後臺服務器上的文件成功。

 

不安全的文件上傳漏洞

不安全的文件上傳漏洞概述文件上傳功能在web應用系統很常見,好比不少網站註冊的時候須要上傳頭像、上傳附件等等。當用戶點擊上傳按鈕後,後臺會對上傳的文件進行判斷 好比是不是指定的類型、後綴名、大小等等,而後將其按照設計的格式進行重命名後存儲在指定的目錄。 若是說後臺對上傳的文件沒有進行任何的安全判斷或者判斷條件不夠嚴謹,則攻擊着可能會上傳一些惡意的文件,好比一句話木馬,從而致使後臺服務器被webshell。 因此,在設計文件上傳功能時,必定要對傳進來的文件進行嚴格的安全考慮。好比:
--驗證文件類型、後綴名、大小;
--驗證文件的上傳方式;
--對文件進行必定複雜的重命名;
--不要暴露文件上傳後的路徑

四、client check

 

 

 有一個提示。

 先判斷是在前端仍是後端有驗證:

 

 查看該函數源碼

 1 function checkFileExt(filename)
 2     {
 3         var flag = false; //狀態
 4         var arr = ["jpg","png","gif"];
 5         //取出上傳文件的擴展名
 6         var index = filename.lastIndexOf(".");
 7         var ext = filename.substr(index+1);
 8         //比較
 9         for(var i=0;i<arr.length;i++)
10         {
11             if(ext == arr[i])
12             {
13                 flag = true; //一旦找到合適的,當即退出循環
14                 break;
15             }
16         }
17         //條件判斷
18         if(!flag)
19         {
20             alert("上傳的文件不符合要求,請從新選擇!");
21             location.reload(true);
22         }
23     }

那能夠直接上傳。

按照要求包裝好一個假的gif

 

 burpsuite抓包抓到手:

 

 修改文件後綴爲php

 

 能夠看到已經上傳成功了

 

 小馬被成功上傳

 

 構造payload

http://your ip/pikachu/vul/unsafeupload/uploads/shengcheng.php?x=1

 

 成功讀取服務器後端數據庫

五、MIME type

 

 這一次並非在前端進行驗證。

 

根據要求修改後綴後上傳

 

 抓包後修改包內內容後上傳:

 

這裏只是加了一個文件類型的判斷。能夠直接略過。

同理:

 

 

五、getimagesize()

 

 發現仍然沒有前端的過濾,可是會斷定是否爲真的圖片。

 (我欺騙你不就是爲了完成做業的嗎我容易嘛我……)

 

提示裏說是對圖片的大小有斷定,那咱們能夠嘗試把木馬藏在圖片裏上傳

 

 先準備一張圖片:

(小聲bb:禰豆子天下第一可愛)

而後修改一下:

 

 發現上傳成功了:

 

 抓包看一下:

 

 老規矩,修改後綴

 

報錯了

 

 並且從以前上傳成功的那一張來看,後端會從新命名你的照片,因此單純修改文件後綴貌似是沒有用的。

 

 (00截斷也不行)

既然咱們已經能把含有木馬的文件上傳至後端,那能夠利用文件包含漏洞讀取木馬了。

先保存路徑:

 

 而後找到以前的文件包含漏洞的網頁:

url修改一下:

 

 多試幾回就能夠了:

http://your ip/pikachu/vul/fileinclude/fi_local.php?filename=../../unsafeupload/uploads/2019/12/22/1787915dfedbd8b2786128645616.jpg&submit=%E6%8F%90%E4%BA%A4%E6%9F%A5%E8%AF%A2

 

 成功讀取出後端數據庫。

相關文章
相關標籤/搜索