SQL Injection 完整實戰入門（一）：B/S 架構風險、防火牆盲區、IE 設定與單引號測試誤區

SQL Injection 威脅背景

• B/S 模式普及，程式設計師水準參差不齊
• 大量程式未驗證使用者輸入合法性
• 攻擊者透過 WWW 正常埠 (80/443) 送入 SQL 代碼
• 防火牆無法識別（外觀與正常瀏覽無異）
• 無 IIS 日誌檢查習慣者，可能長期不知被入侵

攻擊靈活性與高手分水嶺

注入手法極靈活，遇到意外情況需即時分析、構造巧妙 SQL 獲取資料，此為高手與新手根本差異。

國內技術棧分布

• ASP + Access/SQL Server：70%+
• PHP + MySQL：~20%
• 其他：<10%

本系列聚焦 ASP 注入，PHP 部分由 NB 聯盟 zwell 撰寫。

前置準備：IE 設定

工具 → 網際網路選項 → 進階 → 取消勾選「顯示友好 HTTP 錯誤訊息」，否則所有錯誤僅顯示 HTTP 500，無法獲得詳細提示。

第一節：SQL Injection 原理實證

實測目標：https://www.19cn.com/showdetail.asp?id=49 (已獲站長授權)

在 URL 後加單引號 '，回傳錯誤：

Microsoft JET Database Engine error '80040e14'
Syntax error in query expression 'ID=49''.
/showdetail.asp, line 8

洩露關鍵資訊：

1. 使用 Access + JET Engine (非 ODBC)
2. 程式未驗證輸入資料
3. 查詢表包含 ID 欄位

核心原理：

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

第二節：單引號測試的誤區

常見誤解：單引號測試 = 判斷注入點。實際問題：

1. IIS 未必回傳詳細錯誤（可能只顯示通用錯誤頁）
2. 程式若用 CInt(參數) 強制轉型，注入失敗但仍報錯，干擾判斷
3. 部分開發者以為過濾單引號即安全，實際單引號測試會漏報

→ 必須採用更可靠的測試方法（詳見第 2 部分）。