Blind SQL Injection 並不代表完全沒有訊號，而是資料不直接顯示。Boolean-based 類型透過真假條件造成的頁面、狀態碼或資料筆數差異形成側通道。本文以兩個抽象條件比較觀察，避免提供自動擷取流程。
本篇會學到什麼
- 理解布林條件與可觀察差異
- 辨識看似相同頁面的隱藏訊號
- 以參數化與回應設計降低風險
必備名詞與心智模型
如果輸入能改變 WHERE 條件，資料庫可能在條件為真時回傳一列、為假時回傳零列。應用程式再把差異轉成『存在／不存在』、不同內容長度或不同狀態碼。側通道是系統行為差異，不等於某一條特定語法。
發生情境與生活化比喻
訂單查詢只回覆『找到』或『找不到』，不顯示訂單內容。生活化比喻是隔著門問是非題，門內的人不說答案，只用亮燈或熄燈回應。
不安全的原始碼
$reference = $_GET['reference'] ?? '';
$sql = "SELECT id FROM orders WHERE reference='" . $reference . "'";
$exists = (bool) $pdo->query($sql)->fetchColumn();
echo $exists ? '找到訂單' : '找不到訂單';此片段刻意省略連線、路由與部署設定，只用來辨識資料流，請勿放入任何服務。
逐步看懂資料如何變成查詢
- reference 直接進入 WHERE 字串
- 外部資料可能影響條件真假
- 資料庫回傳列數差異
- 應用程式把差異轉成可觀察文字
- 重複比較便可能洩漏原本不應公開的狀態
修補後原始碼
$stmt = $pdo->prepare(
'SELECT id FROM orders WHERE reference=:reference AND owner_id=:owner_id'
);
$stmt->execute(['reference'=>$reference, 'owner_id'=>$sessionUserId]);
$order = $stmt->fetch(PDO::FETCH_ASSOC);
// 未找到與無權限採一致外部回應，詳細原因只留在受控日誌。修補的共同原則是先固定 SQL 結構，再把值獨立綁定；無法作為值綁定的識別字只能從程式內允許清單產生。
如何驗證修補
- 特殊字元只作為 reference 值
- 未找到與無權限回應不洩漏資源是否存在
- 所有查詢綁定目前登入者 owner_id
- 比較狀態碼、長度與關鍵文字時沒有不必要差異
閱讀提醒：以下分析的目的，是讓你能在自己的程式、測試資料與授權環境中辨識風險。面對正式系統時，先取得明確授權並保存變更紀錄；不要用錯誤訊息或一次回應就推論資料外洩，也不要把文章中的概念改造成自動化探測。安全工作的完成條件，是能說明根因、修補位置、回歸結果與剩餘風險。
更多應用情境、常見誤判與觀察方法
把原理放回真實開發情境
布林盲注是以回應差異推測隱藏條件；防守分析要比較狀態碼、內容長度與業務結果。 實作時不要只盯著畫面上的輸入框，還要檢查 API 參數、伺服器端預設值、資料轉換與最後呼叫的資料庫介面。最實用的閱讀方式，是把每一段程式標成「外部來源、轉換、控制、資料庫 sink」，確認資料值沒有在途中重新變回 SQL 結構。
常見誤判
單次頁面不同可能來自快取、A/B 測試或使用者狀態，不能直接當成漏洞證據。 安全判斷不能只靠畫面、單次錯誤或某一個防護產品；應同時看原始碼、驅動程式實際執行方式、資料庫權限與回歸測試。若無法證明查詢結構固定，就應把它視為待修的設計風險。
開發與 SOC 可以觀察什麼
建立正常回應基線，偵測大量相似請求與規律變化；真正修補仍是參數化與結構白名單。 日誌宜記錄時間、路由、請求關聯 ID、查詢名稱、結果狀態與耗時，敏感值則遮罩或雜湊。偵測規則的用途是縮短發現時間；阻擋之後仍須回到程式碼修補，並搜尋其他共用元件與相同資料流。
審查時的三個追問
- 這個值最早由誰控制，經過哪些轉換？
- 它在資料庫呼叫中是資料值，還是欄位、排序、運算式等結構？
- 若預防失效，最小權限、監控與事件流程能限制並發現多少影響？
開發與維運防禦清單
- 參數化固定 WHERE 結構
- 加入物件層級授權，不只判斷是否存在
- 統一敏感資源的外部錯誤
- 監控單一來源大量改變相近查詢參數的行為
重點整理與下一篇
布林盲注利用內容差異；Time-based 類型則利用回應時間。下一篇會說明延遲側通道、網路雜訊與防禦監控。
參考資料與更新日期
更新日期：2026-07-20
