ブラインド - ブラインド SQL インジェクション

エラーメッセージやデータが直接表示されない場合に、真偽値や応答時間の差を利用してデータを推測する手法。

概念図

ブラインド SQL インジェクションは、UNION ベースやエラーベースのように DB の結果やエラー文字列が直接レスポンスに現れない環境で使用される、1 ビットずつ情報を引き出す攻撃手法である。

レスポンスから得られる観測値は「ページが正常か／エラーか」「応答時間が短いか／長いか」といった非常に細かい差分だけだが、これを二分探索で繰り返すことで任意のデータを復元できる。

特徴	内容
観測チャネル	HTTP ステータス / ページ差分 / 応答時間 / Cookie 差分など
情報量	1 クエリあたり 1 ビット（真偽）
クエリ数	文字列長・文字コードに比例して増加（1 文字あたり数クエリ〜）
典型的な標的	検索 API、認証ページ、エラーを握りつぶす本番環境
手動実行の現実性	低い。ほぼ常に自動化ツール前提

ブラインド SQLi は 真偽ベース（Boolean-based） と 時間ベース（Time-based） の 2 系統に大別される。

どちらも注入箇所は UNION ベースと同じだが、観測方法が異なる。

真偽ベースのブラインド SQLi は、条件式の真偽によってレスポンス内容が変化することを利用する。

最も単純な確認ペイロードは次の 2 つである。

-- 真の条件
https://example.test/item?id=1 AND 1=1

-- 偽の条件
https://example.test/item?id=1 AND 1=2

前者で正常ページ、後者で「該当データなし」ページが返るなら、アプリは注入された条件式の結果を漏らしていることになる。

以降、攻撃者は二分探索で情報を抽出する。

-- 管理者パスワードの1文字目が 's' 以降かを判定
1 AND (SELECT ASCII(SUBSTRING(password,1,1)) FROM users WHERE id=1) > 114&#x2D;&#x2D;

-- 真偽で絞り込み、1 文字ごとに文字コードを特定する

この手法は応答時間を増やさないため、時間ベースより高速だが、レスポンス差分をアプリがほとんど返さない（例: 常に 200 でエラーメッセージも単一）環境では成立しない。

時間ベースのブラインド SQLi は、条件が真のときにだけ DB が一定時間スリープするように注入し、応答時間の差で真偽を観測する手法である。

レスポンス本文がまったく変化しない環境でも成立する最後の手段として使われる。

DB	スリープ関数	典型ペイロード
MySQL	`SLEEP(n)`, `BENCHMARK()`	`1 AND IF(SUBSTRING(user(),1,1)='r', SLEEP(5), 0)--`
PostgreSQL	`pg_sleep(n)`	`1; SELECT CASE WHEN (1=1) THEN pg_sleep(5) ELSE pg_sleep(0) END--`
MSSQL	`WAITFOR DELAY '0:0:5'`	`1; IF (1=1) WAITFOR DELAY '0:0:5'--`
Oracle	`DBMS_PIPE.RECEIVE_MESSAGE`	`1 AND 1=(SELECT CASE WHEN (1=1) THEN DBMS_PIPE.RECEIVE_MESSAGE('X',5) ELSE 1 END FROM DUAL)--`

時間ベースは確実だが 1 ビットあたり数秒かかるため、非常に低速になる。

そこでほぼ必ず自動化ツールが使われる。

代表的なものが SQLMap（オープンソース）で、以下を自動で実行する。

防御側としては、短時間に条件式を少しずつ変えた大量リクエストが同一 IP / 同一セッションから来るパターンは、WAF の振る舞い検知や IDS/IPS ルールで観測可能である。

ネットワーク層でのレート制限とアプリ層の監査ログを組み合わせると、自動化ツールの利用を早期に発見しやすい。