首先，我明白自己要做的不是找到這個上傳的位置是哪裡出現的，我應該登上伺服器進行webshel查殺，進行巡檢，找找看是否被別人入侵了，是否有後門等等情況。雖然報的是我們公司的ip位址，萬一漏掉了幾個webshell，被別人上傳成功了沒偵測出來，那伺服器被入侵瞭如何能行。所以我上去巡檢了伺服器，上傳這個webshell查殺工具進行查殺，使用netstat -anpt和iptables -L判斷是否存在後門建立，查看是否有挖礦程序佔用CPU，等等，此處不詳細展開了。萬幸的是伺服器沒有被入侵，然後我開始著手思考這個上傳點是怎麼回事。
首先，我向這個和我對接的研發人員諮詢這個伺服器對外開放的地址，要了地址之後打開發現，眼熟的不就是前不久自己測試的嗎？此時，我感覺有點懵逼，和開發人員對質起這個整改信息，上次測試完發現這個上傳的地方是使用了白名單限制，只允許上傳jpeg、png等圖片格式了。當時我還發現，這個雖然上傳是做了白名單限制，也對上傳的文件名做了隨機數，還匹配了時間規則，但是我還是在返回包發現了這個上傳路徑和文件名，這個和他提議要進行整改，不然這個會造成這個文件包含漏洞，他和我回饋這個確實進行整改了，沒有回傳這個路徑了。
討論回顧完上次整改的問題之後，理清了思路。然後我登入了網站查看原因，因為網站只有一個上傳圖片的地方，我進行抓包嘗試，使用了repeater重播包之後，發現返回包確實沒有返回文件上傳路徑，然後我又嘗試了各種繞過，結果都不行。最後苦思冥想得不到結果，然後去問這個雲端平台給他們的這個告警是什麼原因。看了雲端平台回饋的結果裡面查殺到有圖片碼，這個問題不大，上傳檔案沒有執行權限，而且沒有返回檔案路徑，還對檔案名稱做了隨機更改，但是為啥會有這個jsp上傳成功了，這讓我百思不得其解。
當我仔細雲端平台提供的發現webshel資料的時候，我細心的觀察到了檔案名稱使用了base64編碼，這個我很疑惑，都做了隨機函數了還做編碼幹嘛，上次測試的時候是沒有做編碼的。我突然想到了問題關鍵，然後使用burpsuite的decoder模組，將文件名“1.jsp”做了base64編碼成“MS5Kc1A=”，然後發送成功反饋狀態碼200，再不是這個上傳失敗反饋500狀態碼報錯了。
所以，這個問題所在是，在整改過程中研發人員對這個檔案名稱使用了base64編碼，導致檔案名稱在儲存過程中會使用base64解碼，而我上傳檔案的時候將這個後綴名.jsp也做了這個base64編碼，在預存過程中.jsp也被成功解碼，研發沒有對解碼之後進行白名單限制。其實這種編碼的更改是不必要的，畢竟原來已經做了隨機數字更改了檔名了，再做編碼有點畫蛇添足了，這就是為啥程序bug改一個引發更多的bug原因。
以上是webshell被上傳溯源事件的範例分析的詳細內容。更多資訊請關注PHP中文網其他相關文章！
