當內容與錯誤都看不出差異，資料庫運算造成的時間差仍可能成為訊號。Time-based Blind SQL Injection 的重點是『可控條件是否能改變處理時間』，不是把偶發慢速直接判定為漏洞。
本篇會學到什麼
- 理解延遲側通道與網路雜訊
- 分辨應用延遲、資料庫延遲與基礎設施延遲
- 建立逾時、資源限制與異常監控
必備名詞與心智模型
一次請求慢可能是快取、網路、鎖或負載。可信判斷需要基準線、重複樣本與伺服器端追蹤。若不可信資料能改變 SQL 結構，條件式高成本運算或等待行為可能讓真假反映在時間上。文章不提供跨站測時或自動推測程式。
發生情境與生活化比喻
報表端點接受日期與排序，正常回應約數百毫秒，某些輸入卻穩定拖長資料庫執行。生活化比喻是看不到房間內的答案，但可以從對方回應快慢猜測某個條件。
不安全的原始碼
$filter = $_GET['filter'] ?? '';
$sql = "SELECT id,total FROM reports WHERE label='" . $filter . "'";
$rows = $pdo->query($sql)->fetchAll();此片段刻意省略連線、路由與部署設定，只用來辨識資料流，請勿放入任何服務。
逐步看懂資料如何變成查詢
- filter 跨越信任邊界
- 拼接允許輸入影響資料庫解析
- 不同條件可能造成不同執行成本
- 回應時間把內部差異帶到外部
- 若持續重複請求，資料庫資源也可能被消耗
修補後原始碼
$stmt = $pdo->prepare(
'SELECT id,total FROM reports WHERE label=:label AND created_at>=:start'
);
$stmt->execute(['label'=>$filter, 'start'=>$validatedStartDate]);
$rows = $stmt->fetchAll(PDO::FETCH_ASSOC);
// 另於驅動與資料庫設定合理 statement timeout。修補的共同原則是先固定 SQL 結構，再把值獨立綁定；無法作為值綁定的識別字只能從程式內允許清單產生。
如何驗證修補
- 用多次正常請求建立延遲分布，不靠單一樣本
- 特殊輸入不改變查詢結構與 execution plan 類型
- 應用、資料庫與反向代理逾時互相一致
- 慢查詢日誌能連結事件 ID、端點與查詢指紋
閱讀提醒：以下分析的目的，是讓你能在自己的程式、測試資料與授權環境中辨識風險。面對正式系統時，先取得明確授權並保存變更紀錄；不要用錯誤訊息或一次回應就推論資料外洩，也不要把文章中的概念改造成自動化探測。安全工作的完成條件，是能說明根因、修補位置、回歸結果與剩餘風險。
更多應用情境、常見誤判與觀察方法
把原理放回真實開發情境
時間型訊號必須用多個樣本與分布判讀，並排除網路、快取、鎖競爭和冷啟動。 實作時不要只盯著畫面上的輸入框，還要檢查 API 參數、伺服器端預設值、資料轉換與最後呼叫的資料庫介面。最實用的閱讀方式，是把每一段程式標成「外部來源、轉換、控制、資料庫 sink」，確認資料值沒有在途中重新變回 SQL 結構。
常見誤判
一次變慢不是漏洞；只調低逾時也可能傷害正常使用者，且沒有處理根因。 安全判斷不能只靠畫面、單次錯誤或某一個防護產品；應同時看原始碼、驅動程式實際執行方式、資料庫權限與回歸測試。若無法證明查詢結構固定，就應把它視為待修的設計風險。
開發與 SOC 可以觀察什麼
監控端應關聯應用延遲、DB wait、鎖與查詢指紋，找出規律重複且成本升高的請求。 日誌宜記錄時間、路由、請求關聯 ID、查詢名稱、結果狀態與耗時，敏感值則遮罩或雜湊。偵測規則的用途是縮短發現時間；阻擋之後仍須回到程式碼修補，並搜尋其他共用元件與相同資料流。
審查時的三個追問
- 這個值最早由誰控制，經過哪些轉換？
- 它在資料庫呼叫中是資料值，還是欄位、排序、運算式等結構？
- 若預防失效，最小權限、監控與事件流程能限制並發現多少影響？
開發與維運防禦清單
- 參數化是根本修補，逾時不是替代品
- 限制報表日期範圍與回傳筆數
- 監控 p95/p99、資料庫 CPU、鎖等待與同源重複請求
- 避免把原始 SQL 與完整參數寫進可廣泛存取的監控平台
重點整理與下一篇
前幾篇多從 SELECT 出發；下一篇會說明 INSERT、UPDATE、DELETE 以及資料先儲存、之後才觸發的 Second-order Injection。
參考資料與更新日期
更新日期：2026-07-20
