ASP Request 對象深度剖析與 SQL 注入防禦實戰

在經典 ASP 開發中，Request 內建對象是獲取 HTTP 請求數據的核心入口，亦是 SQL 注入攻擊的主要攻擊面。本文將系統梳理 Request 的集合結構、優先級機制，並揭示通用防注入方案中常被忽視的 Cookies 繞過風險。

Request 對象的六大數據集合

Request 封裝了 HTTP 請求中的所有信息，按來源分為六大集合：

• QueryString — GET 參數
• Form — POST 表單數據
• Cookies — Cookie 數據
• ServerVariables — 伺服器變量（固定集合）
• ClientCertificate — 客戶端憑證（固定集合）
• Browser — 瀏覽器能力信息（固定集合）

前三者變量名可任意指定，後三者為系統預定義。

簡寫語法 Request(key) 的隱含優先級

直接使用 Request("key") 時，ASP 會依次搜尋上述六大集合，首個匹配即返回。實測優先級順序為：

1. QueryString
2. Form
3. Cookies
4. ServerVariables
5. ClientCertificate
6. Browser

實驗驗證：同名參數 b 分別以 GET、POST、Cookie 傳遞，GET 值「He」覆蓋 POST 值「She」；Telnet 手工構造 Cookie 頭同樣可注入數據（注意空格需 URL 編碼）。

SQL 注入根源：參數未經過濾直入動態 SQL

ASP 下的 SQL 注入本質上是 Request 參數未經嚴格過濾即拼接進 SQL 語句。常見通用防注入方案（如「SQL 通用防注入系統」）採用遍歷 QueryString 與 Form 集合、匹配關鍵字黑名單（and、select 等）的策略，卻漏掉了 Cookies 集合。

實戰繞過場景重現

1. 應用全站使用 Request(key) 獲取參數。
2. 管理員部署了僅檢查 QueryString/Form 的通用防注入 Include 文件。
3. 攻擊者將惡意 Payload 放入 Cookie 中（如 id=1 OR 1=1）。
4. Request("id") 因優先級機制先讀到 QueryString/Form 無惡意內容而放行，實際執行時卻從 Cookies 取到注入代碼。

此漏洞源於「防禦邏輯與數據獲取方式不匹配」，而非語言本身缺陷。

修補建議

• 參數化查詢：使用 Command 對象 + Parameters 集合，徹底隔離代碼與數據。
• 白名單驗證：針對業務欄位定義允許字符集/正則，拒絕黑名單思維。
• 統一入口過濾：若必須用舊代碼，請在全局 Global.asa 或公共 Include 中遍歷 所有六大集合，或顯式指定 Request.QueryString/Form/Cookies 避免優先級陷阱。
• 最小權限原則：資料庫連接帳號僅授予必要權限，禁止 xp_cmdshell 等危險擴展。

總結

Request 對象的便利性源於其聚合特性，但這聚合機制若被誤解，便會成為安全黑洞。深入理解集合優先級、拒絕盲目依賴黑名單、堅持參數化查詢，才是 ASP 應用防注入的正道。