MySQL SQL 注入風險：理解 load_file() 利用與防禦策略

在 MySQL 資料庫應用中，SQL 注入一直是最嚴重的安全威脅之一。本文深入探討 MySQL 內建函數 load_file() 在注入攻擊中的濫用風險，並說明如何透過安全配置與程式碼審查來降低風險。

核心風險：load_file() 函數特性

MySQL 的 load_file() 函數可讀取伺服器端檔案並以字串形式返回內容。若應用程式存在 SQL 注入漏洞，攻擊者可利用此函數讀取敏感檔案（如 /etc/passwd、Web 設定檔等）。但執行條件嚴格：

• 目標檔案必須存在於資料庫伺服器本機
• 需提供完整絕對路徑
• 資料庫進程需具備檔案讀取權限
• 檔案大小不得超過 max_allowed_packet 設定值

Windows 環境下若 NTFS 權限設定得當，可有效限制非管理員帳號讀取系統檔案。

實戰攻擊向量分析

典型注入點多出現在未經過濾的參數中，例如：

SELECT * FROM article WHERE articleid=$id

當 magic_quotes_gpc = Off 時，攻擊者可直接構造 UNION SELECT load_file('c:/boot.ini') 讀取檔案。若開啟 magic_quotes_gpc，則需繞過單引號過濾，常見手法包括：

• 使用 CHAR() 函數將路徑轉為 ASCII 碼：load_file(char(99,58,47,...))
• 使用十六進位表示法：load_file(0x633a2f626f6f742e696e69)

若回顯條件受限，攻擊者可結合 INTO OUTFILE 將檔案內容導出至 Web 可存取目錄，再透過 HTTP 下載。

真實案例複盤：某知名主機商論壇測試

作者曾對某 FreeBSD 主機提供商的 VBB 論壇進行授權滲透測試。該論壇 global.php 會主動移除 magic_quotes_gpc 添加的轉義字元，導致無論 PHP 設定如何，單引號均可直接注入。測試流程：

1. 透過 phpinfo() 洩露的 Web 絕對路徑：/home/4ngel
2. 發現可寫目錄：/home/4ngel/soft/
3. 利用 calendar.php 注入點，構造 UNION SELECT load_file(...) 讀取論壇設定檔 /home/4ngel/forum/admin/config.php 及系統 /etc/passwd
4. 使用 INTO OUTFILE '/home/4ngel/soft/cfg.txt' 導出檔案
5. 透過 Web 直接下載導出檔案，獲取資料庫連線憑證與系統帳號資訊

此攻擊鏈展示了單一注入點配合 load_file() 即可導致伺服器完全失陷，危害極大。

防禦建議與最佳實務

1. 參數化查詢與預處理語句

徹底杜絕 SQL 拼接，使用 PDO 或 MySQLi 預處理語句，將使用者輸入視為資料而非程式碼。

2. 最小權限原則

• 資料庫布號僅授予必要權限（SELECT、INSERT、UPDATE），嚴禁授予 FILE 權限
• 作業系統層面限制資料庫進程讀取敏感目錄（/etc、Web 設定目錄等）

3. 錯誤訊息隱藏

生產環境關閉 display_errors，避免路徑洩露協助攻擊者構造 load_file() 路徑。

4. 禁用高風險函數

若業務不需檔案讀取，可在 my.cnf 中設定 secure_file_priv 限制 load_file() 與 INTO OUTFILE 的存取目錄，或透過資料庫防火牆攔截含此函數的查詢。

5. 定期審計與監控

啟用資料庫審計日誌，監控異常 UNION SELECT、load_file()、INTO OUTFILE 等高風險語句。

結語

load_file() 屬於 MySQL 合法功能，但若配合 SQL 注入漏洞，將成為攻擊者奪取伺服器控制權的利器。防禦核心在於：修補注入漏洞、收回 FILE 權限、隔離檔案系統存取。安全開發人員應將此風險納入威脅模型，從程式碼審查、資料庫配置、作業系統加固多層面佈防。