隨著 B/S 架構應用的普及，越來越多開發者投入 Web 程式編寫。然而，門檻較低導致程式碼品質參差不齊，許多開發者未對使用者輸入進行嚴格驗證，從而埋下 SQL 注入隱患。攻擊者透過提交精心構造的資料庫查詢代碼，利用程式回傳的錯誤訊息或資料，竊取敏感資訊——這就是所謂的 SQL Injection。

SQL 注入的隱蔽性與危害

SQL 注入攻擊走的是正常 WWW 連接埠（80/443），外觀與一般網頁瀏覽無異，傳統防火牆難以攔截。若管理員缺乏檢視 IIS 日誌習慣，系統可能長期被滲透而不自知。注入手法靈活多變，能否根據實際情況構造巧妙 SQL 語句，是區分高手與新手的關鍵。

國內資料庫使用現況

據統計，國內網站超過 70% 採用 ASP 搭配 Access 或 SQL Server，PHP + MySQL 佔約 20%，其餘不足 10%。本系列將由淺入深講解 ASP 注入技術，PHP 部分由 NB 聯盟 zwell 專文闡述，旨在為安全從業者與開發者提供參考。即使熟悉注入原理，也建議閱讀入門篇，因常見判斷方法仍存誤區。

入門篇：環境準備與核心原理

1. 瀏覽器設定：顯示詳細錯誤

初次測試前，請在 IE 中依序點選「工具 → 網際網路選項 → 進階」，取消勾選「顯示友好 HTTP 錯誤訊息」。否則伺服器回傳的詳細錯誤將被 IE 統一替換為「HTTP 500 伺服器錯誤」，導致無法獲取關鍵提示。

2. SQL 注入原理實例

以某站點（已獲授權）為例，首頁連結「IE無法開啟新視窗的多種解決方法」對應網址 ?id=49。在參數後附加單引號 '，伺服器回傳：

Microsoft JET Database Engine 錯誤 '80040e14'
字串的語法錯誤 在查詢運算式 'ID=49'' 中。
/showdetail.asp，行 8

從錯誤可推斷：

• 使用 Access 資料庫，透過 JET 引擎連線（非 ODBC）。
• 程式未驗證用戶端提交資料的合法性。
• 查詢資料表包含名為 ID 的欄位。

核心原理：客戶端提交特殊代碼 → 收集程式/伺服器資訊 → 獲取目標資料。

3. 判斷注入點的科學方法

單純測試單引號並非最佳策略，原因有二：

1. 部分伺服器不回傳詳細錯誤，或程式使用 CInt(參數) 等強制轉型，導致注入失敗卻同樣報錯。
2. 開發者可能僅過濾單引號，誤以為安全，實則無法阻擋數字型參數注入。

經典 1=1 / 1=2 判斷法（針對數字型參數）：

測試 Payload	預期回應
?id=49	正常顯示（基準）
?id=49; and 1=1	正常顯示，內容與基準一致
?id=49; and 1=2	出現 BOF/EOF、找不到記錄、或內容為空（視程式邏輯而定）

若三者表現符合上表，即存在注入點。若 1=1 與 1=2 均報程式定義錯誤或型別轉換錯誤，則不可注入。字串型、搜尋型參數判斷將在進階篇說明。

4. 判斷資料庫類型與注入策略

不同資料庫函數、語法差異大，需先識別後端 DBMS。常見判斷手段包括：

• Access：and exist(select * from msysobjects)>0（需權限）或利用 JET 專屬錯誤特徵。
• SQL Server：and user>0、and db_name()>0 觸發型別轉換錯誤洩露使用者/資料庫名。
• Oracle：and 1=ctxsys.drithsx.sn(1,chr(65)) 等專屬函數。

識別後即可針對性構造 Payload，進階篇將詳細講解各類資料庫的注入技巧與系統表利用。