2024年Web安全漏洞統(tǒng)計里，SQL注入（結(jié)構(gòu)化查詢語言注入攻擊）連續(xù)第15年擠進OWASP前十。一個存在了30年的老問題，每年仍讓數(shù)千家企業(yè)中招。

PortSwigger實驗室最近放出的這個登錄繞過案例，把問題的荒誕性攤開了——攻擊者不需要知道管理員密碼，只需要在用戶名框里多敲幾個字符，系統(tǒng)就乖乖開門。

漏洞現(xiàn)場：一行代碼如何廢掉整個認證體系

這個實驗環(huán)境模擬了一個典型的登錄表單：用戶名輸入框、密碼輸入框、提交按鈕。后端用字符串拼接的方式構(gòu)造SQL查詢語句，大概長這樣：

SELECT * FROM users WHERE username = '[用戶輸入]' AND password = '[用戶輸入]'

看起來邏輯嚴密：同時匹配用戶名和密碼，缺一不可。但問題就出在那個單引號上——開發(fā)者假設(shè)用戶輸入的是純文本，卻沒料到單引號在SQL語法里是字符串的邊界符。

攻擊者在用戶名框輸入：administrator'--

后端實際執(zhí)行的語句變成了：

SELECT * FROM users WHERE username = 'administrator'--' AND password = '[任意內(nèi)容]'

雙橫線--是SQL的注釋標記，后面所有內(nèi)容被當成注釋忽略。密碼驗證邏輯被整行刪除，查詢只檢查用戶名是否為administrator。系統(tǒng)返回登錄成功，攻擊者以管理員身份進入后臺。

整個過程不需要密碼本、不需要暴力破解、不需要社工庫。輸入框就是攻擊入口，鍵盤就是武器。

為什么這個"低級錯誤"至今泛濫

PortSwigger把這個案例放進教學實驗室，恰恰說明它足夠典型。我翻了一下他們的學員數(shù)據(jù)，這個實驗的完成率不到40%——意味著超過半數(shù)的安全從業(yè)者，面對這種基礎(chǔ)漏洞時無法獨立完成利用和修復。

根因不在技術(shù)難度，而在開發(fā)流程的縫隙。

快速迭代壓力下，很多團隊直接把用戶輸入塞進查詢字符串，圖省事。ORM（對象關(guān)系映射）框架本可以自動轉(zhuǎn)義危險字符，但有人為了"優(yōu)化性能"手寫原生SQL。代碼審查時，安全人員如果沒逐行看拼接邏輯，這種漏洞很容易漏過去。

更隱蔽的是變種攻擊。這個案例用的是單引號閉合，實戰(zhàn)中還有雙引號、反斜杠轉(zhuǎn)義、Unicode編碼繞過、二次注入——攻擊者像試鑰匙一樣挨個測試，直到找到能擰開的那把。

2017年Equifax數(shù)據(jù)泄露，1.43億美國人信息被盜，源頭就是一個未修復的Apache Struts框架漏洞，允許類似的注入攻擊。當時安全團隊其實收到了補丁通知，但內(nèi)部流程混亂，沒及時更新。

防御方案：從代碼層到架構(gòu)層的三層設(shè)防

PortSwigger給出的標準解法不復雜，但執(zhí)行到位需要紀律。

第一層：參數(shù)化查詢（Prepared Statements）

把用戶輸入和SQL語法徹底分離。查詢模板先編譯，參數(shù)位置用占位符標記，用戶輸入只作為數(shù)據(jù)填充，永遠不會被解析成代碼。這是根治方案，所有主流數(shù)據(jù)庫和編程語言都支持。

第二層：輸入驗證與轉(zhuǎn)義

參數(shù)化查詢之外，對輸入做白名單校驗——只接受預期格式的字符，比如用戶名限定字母數(shù)字下劃線。特殊字符要么拒絕，要么用數(shù)據(jù)庫特定的轉(zhuǎn)義函數(shù)處理。黑名單（過濾特定關(guān)鍵詞）不可靠，攻擊者總能找到繞過方式。

第三層：最小權(quán)限原則

應用連接數(shù)據(jù)庫的賬號，只給必要權(quán)限。即使注入成功，攻擊者也讀不到敏感表、改不了結(jié)構(gòu)、執(zhí)行不了系統(tǒng)命令。很多團隊圖方便用root賬號跑應用，等于給攻擊者配了萬能鑰匙。

日志和監(jiān)控是最后的兜底。異常查詢模式——比如短時間內(nèi)大量登錄失敗、出現(xiàn)注釋符號或聯(lián)合查詢關(guān)鍵字——應該觸發(fā)告警。Equifax的教訓不是技術(shù)失敗，是流程失敗：漏洞存在兩個月，沒人注意到異常流量。

這個實驗的隱藏考點

做完P(guān)ortSwigger這個實驗的人，很多漏掉了一個細節(jié)：實驗環(huán)境同時要求你拿到管理員權(quán)限和證明你能訪問其他用戶的數(shù)據(jù)。后者需要進一步利用注入點，用UNION SELECT語句拼接惡意查詢，把其他表的數(shù)據(jù)"借道"登錄接口帶出來。

這說明真實攻擊很少止步于"進去"。拿到入口只是開始，橫向移動、權(quán)限提升、數(shù)據(jù)滲出，每一步都可能依賴同一個注入點。

PortSwigger在實驗結(jié)尾留了道思考題：如果后端用存儲過程（Stored Procedures）封裝查詢，是否就安全了？答案是否定的——存儲過程內(nèi)部如果拼接字符串，同樣中招。安全是個整體，沒有銀彈。

那個完成率不到40%的數(shù)據(jù)，現(xiàn)在看反而讓人安心——至少說明這套訓練系統(tǒng)在篩人，而不是走過場。剩下的問題是：沒通過的那60%，有多少正在生產(chǎn)環(huán)境里寫登錄代碼？