一個文件上傳漏洞靶場
靶機說明：
步驟Web應用程序是一組輪詢的背景圖像，同時它也允許上傳自己圖像。
檢測內容
首先頁面本身沒有透露什么太有趣的內容。那就從模糊測試開始，看看能不能找到更多內容：
ffuf -w /usr/share/wordlists/dirb/big.txt -u http://jewel.uploadvulns.thm/FUZZ
果然成功找到了更多的目錄。快速瀏覽一下 CSS，你就會發現旋轉的背景圖像是從目錄/content/中獲取的。該目錄/admin/顯示一條注釋，這就說明可以在這里激活一些模塊。
其他目錄并沒有顯示出其他什么有用的內容。
檢測使用的技術
下一步是找出頁面使用了什么技術，同時看看它們可能引用了哪些模塊類型。因此我用Wappalyzer檢查了一下頁面：
這里顯示出來的是在Express框架上運行的node.js應用程序。
在子目錄中查找內容
接下來我檢查子目錄去查找其他內容。提供的單詞列表中的命名模式與圖像的命名模式匹配，因此我也使用該列表檢查/content/目錄。
ffuf -w ./UploadVulnsWordlist.txt -u http://jewel.uploadvulns.thm/content/FUZZ.jpg
果然，它找到了四個用作背景的圖像。
獲取反向shell的腳本
因為我知道該應用程序是一個Node.js應用程序，所以我從PayloadsAllTheThings那里得到了一個反向shell，并更改了IP /端口來匹配自己服務器：
上傳shell
本來想說嘗試上傳腳本，但它被阻止了。不過這是一個由JavaScript觸發的消息，因此我使用Burp歷史記錄來檢查加載的腳本文件。
然后我就找到了罪魁禍首，客戶端驗證代碼：/assets/js/upload.js
如果要攔截JavaScript文件，我需要更改代理選項以攔截JS文件，因為默認情況下Burp Proxy是不會攔截它們的：
刪除條件^.js$后，使用Ctrl-F5重新加載頁面來實現強制完全刷新。
當upload.js請求被攔截時，再指示Burp攔截其響應（Do Intercept->Response to this request）并刪除上面標記的行。
雖然我已經試圖重新上傳了，但它還是失敗了，這次是在服務器端完成的驗證。
在理想情況下，服務器應執行客戶端執行的所有驗證。畢竟客戶端驗證只是為了可用性。最終的安全性只能通過服務器端驗證來提供。
不過現實很骨感，服務器執行了其他驗證。我將文件擴展名更改為jpg并重試上傳。這一次它成功了。
查找已上傳的shell
我剛剛上傳的文件在任何目錄中都找不到其已知文件名。然后我使用提供的單詞列表重新運行目錄的模糊測試。
這一次，我在那里找到了一個額外的文件：
獲取反向shell
在/admin/頁面上，我可以激活/modules/目錄中的模塊，服務器應該強制它不接受任何其他位置。
我剛剛上傳的文件位于/content/ .不過可能沒有適當的驗證來防止路徑遍歷。
然后我在我的機器上啟動一個監聽器nc -nvlp 8888，并通過其相對路徑激活模塊：../content/WON.jpg
我收到的 shell 顯示應用程序以 root 身份運行。因此，不需要權限提升，我可以立即獲得flag：
