前言

在資料庫安全領域，MSSQL 的 SA (System Administrator) 權限向來被視為最高權限，一旦被惡意利用，後果不堪設想。本文透過實戰案例剖析，說明攻擊者如何結合 SQL 注入、SA 權限與後台上傳功能獲取 WebShell，並提供相應防禦建議。

攻擊鏈條分析

前置條件

• 目標存在 SQL 注入漏洞，且資料庫為 MSSQL。
• 資料庫連接使用 SA 高權限帳號。
• 網站後台具備檔案上傳功能。

實戰過程

攻擊者首先透過工具 (如 NBSI) 驗證注入點與權限，接著尋找上傳路徑 (例如 /admin/uploadpic/)，利用 NB Commander 遍歷目錄獲取網站絕對路徑 (如 D:\9x3x9)。嘗試破解後台帳密失敗後，改為讀取連線檔 (conn.asp) 與權限驗證檔 (quanxian.asp)，發現僅驗證 Session 變數 Session("wsl")=1。攻擊者上傳偽造 Session 的 ASP 檔案 (1.asp)，成功繞過驗證進入後台。隨後將 ASP 木馬偽裝為 GIF 上傳，再利用複製/重命名技巧將其轉為可執行的 ASP 檔案，最終植入 WebShell。

核心風險點

• SA 權限過度授權：應用程式連接資料庫不應使用 SA，應遵循最小權限原則。
• 擴展預存程序殘留：xp_cmdshell 等危險功能若未使用應移除，否則成為攻擊利器。
• 上傳驗證缺失：僅檢查副檔名、未驗證檔案內容與 MIME 類型，允許雙重副檔名繞過。
• Session 機制脆弱：單一 Session 變數控制權限，且未綁定使用者身份與來源 IP。

防禦建議

1. 資料庫帳號分級：Web 應用使用僅具備必要 CRUD 權限的專用帳號，嚴禁使用 SA。
2. 移除/禁用危險元件：刪除 xp_cmdshell、sp_OACreate 等擴展預存程序；啟用 MSSQL 表面積配置最小化。
3. 強化上傳功能：實施白名單驗證副檔名、檢查 Magic Number、重新命名儲存檔案、儲存目錄設為不可執行、使用獨立儲存服務。
4. 完善 Session 管理：Session 應包含使用者 ID、角色、登入時間、IP 綁定；設定合理逾時；重要操作需二次驗證。
5. 輸入驗證與參數化查詢：全面採用參數化查詢預防 SQL 注入；部署 WAF 規則攔截可疑載荷。
6. 目錄遍歷防護：關閉不必要的目錄列舉功能；錯誤訊息不回顯伺服器路徑。

總結

SA 權限一旦外洩，配合常見功能缺陷極易導致伺服器淪陷。開發與運維團隊必須從架構、程式碼、設定三個層面落實最小權限與纖深防禦，才能有效降低風險。