前言：安全公司也會「鞋匠腳底漏」

作者出於好奇，對某廣州知名網絡安全公司官網進行授權測試（文中已脫敏）。常規漏洞掃描器（X-scan、Nmap、Retina）僅發現開放 TCP 80 端口，無明顯漏洞。轉而嘗試 SQL 注入，意外發現其論壇登錄頁存在高危注入點，最終拿下後台管理權限。

注入點發現與驗證

目標 1：軟件下載頁 /download/open.asp?id=3444

測試單引號 '、雙引號 "、' or 1=1-- 等經典 Payload，均返回 HTTP 500，推測有過濾或錯誤處理機制，未直接回顯。

目標 2：論壇列表頁 /forum/list.asp?ltid=14

同樣測試各類 Payload，均返回錯誤頁面，疑有 WAF/過濾。

目標 3：論壇登錄框（突破口）

嘗試用戶名/密碼欄注入：
用戶名：版主帳號' or 1=1-- → 失敗
密碼：' or 1=1-- → 失敗
多種變體均失敗。

目標 4：論壇「版面登錄」彈窗（關鍵突破）

發現論壇登錄區上方小鏈接「版面登錄」，點擊彈出獨立登錄窗口（/forum/login.asp?boardid=1）。
在此窗口測試：

• 用戶名：版主帳號' or 1=1--，密碼任意 → 失敗
• 用戶名：版主帳號，密碼：' or 1=1-- → 成功繞過認證，進入後台！

後台顯示「刪除」等管理按鈕，證明獲得管理員權限。

漏洞根因分析

代碼邏輯大致為：

sql = "SELECT * FROM users WHERE username='" & txtUser & "' AND password='" & txtPass & "'"

密碼欄未過濾單引號，構造 ' or 1=1-- 使 WHERE 條件恆真：
... WHERE username='版主帳號' AND password='' or 1=1--'
-- 註釋掉後續單引號，SQL 執行返回該用戶第一行記錄（即版主），登錄成功。

為什麼其他頁面不工作？

• 下載頁/列表頁可能使用了參數化查詢/存儲過程，或有 WAF 針對 URL 參數過濾。
• 主登錄頁可能對用戶名/密碼雙雙過濾，或使用了不同查詢邏輯。
• 「版面登錄」彈窗為獨立開發模塊，代碼復用不當，漏網之魚。

安全啟示：魔高一尺，道高一丈

1. 安全公司自身業務代碼同樣需 SDL (Security Development Lifecycle) 保障：威脅建模、代碼審計、滲透測試、上線前驗收。
2. 統一輸入驗證框架：全站強制使用參數化查詢/ORM，禁止字符串拼接 SQL。
3. 最小權限數據庫賬號：Web 應用連接數據庫賬號僅擁有必要表的 SELECT/INSERT/UPDATE，無 DROP/ALTER/系統表權限。
4. 錯誤信息不回顯：生產環境關閉詳細錯誤頁面（Custom Errors=On），避免洩露表結構、SQL 片段。
5. WAF 非銀彈：需結合代碼層面修復，WAF 只能加擋不堵漏。
6. 定期授權滲透測試：內部紅隊/外部專業機構，覆蓋所有業務入口（含子域名、API、移動端、管理後台）。

後記

作者僅演示登錄繞過，未進行任何破壞操作（刪帖/改數據），並第一時間通知廠方修復。安全研究底線：授權、無損、負責任披露。