有一天客戶的 IT 人員從資料庫中發現，某些資料欄位被塞入不尋常的資料。
看到這些資料的當下，我第一個念頭是「會不會某支程式有 Bug 導致整批資料被更新了？」，在排除這個原因之後，調查方向轉往「可能被駭客入侵了？」的狀況前進。
拿這個不尋常的資料「WF_SQL_XSRF.html」丟到 Google 搜尋，從搜尋結果中發現這是網站被植入了 Cross Site Scripting (XSS) 的程式碼，問題是怎麼被植入的？
我直覺是 SQL Injection 來的，於是我試著去找 IIS Log 看有沒有留下什麼？還真的有一些異常的瀏覽記錄。
被 SQL Injection 是舊網站，用 ASP.NET 開發的，正當我要去 Web Server 先做一點緊急應變時，我又發現了一個令人毛骨悚然的檔案「ASPXspy.aspx」，這不是著名的後門程式嗎！？
看來是中了 Web Shell 的攻擊，太慘了，不僅被 SQL Injection，還被上傳了 Web Shell 後門程式。
WAF（Web Application Firewall）
舊網站大概有將近一千支 *.aspx 網頁，一支一支去檢查有沒有 SQL Injection 的漏洞緩不濟急，緊急將舊網站加到 WAF 服務底下，先渡過這關再說，WAF 服務的話 Cloudflare 就有現成的可以用。
Web Shell
再來要處理 Web Shell 的漏洞，後門程式會出現在網站目錄裡面，推論它應該是從有上傳功能的網頁進來的，經過一番搜索後，整個網站能上傳檔案的就只有一個地方。
這段程式碼要修補的地方至少有兩個：
- 只依賴 ContentType 來驗證檔案格式
- 使用 User 給的檔名／副檔名來儲存檔案
所以，我只要偽造 ContentType 上傳 ASPXspy.aspx 檔案，就能輕鬆將後門程式放到 Web Server，而 Web Shell 不是只有 ASP.NET 會中，PHP、JSP、...都會，我們到網路去搜尋「Web Shell GitHub」就能找到一堆主流程式語言的 Web Shell 後門程式檔案。
即戰力？即戰慄？
客戶在草創的時候，高薪找了一批「即戰力」工程師進來發展系統，老闆親自面試，但是老闆不懂技術啊！
現在這批工程師已經都不在了，但是程式碼還在，很顯然地，寫這段程式碼的工程師對 HTTP 的相關知識了解得不夠細微，以致於他有想到要去驗證使用者上傳的內容，但用錯了方法，因而留了個洞在那兒，「即戰力」變成了「即戰慄」。
就這次的攻擊事件結果來看，我這個客戶的運氣相當好，駭客算是手下留情了，不然，埋了一個後門在那邊，想做什麼都可以，刪光檔案及資料庫就只是幾行指令跟時間而已。
