PR 本記事には広告(Amazonアソシエイト・もしもアフィリエイト・A8.net等)が含まれます。掲載情報の正確性には努めていますが、商品の詳細は必ずリンク先で最新情報をご確認ください。

【ブラインドSQLi編】結果が見えなくても起きるSQL注入と守り方|CTF思考フレームワーク #32

【ブラインドSQLi編】見えない応答から1ビットずつ抜く攻撃と守り方|CTF思考フレームワーク #32 アイキャッチ画像
安全に生きたい編集部

エラーもデータも画面に出ていないなら、SQLインジェクションは起きない?

画面の変化や応答時間の差だけでも、条件が真か偽かを推測できる場合があるんだ。

ブラインドSQLインジェクションは、データベースの結果が直接表示されなくても、応答の違いを手掛かりに情報を推測される問題です。

ただし、抽出に要する時間や可能な範囲は、アプリの挙動、制限、データ量によって大きく変わります。「必ず短時間で全件抜かれる」と言い切るのは適切ではありません。

📚 CTF思考フレームワーク シリーズ

#32 【ブラインドSQLi編】結果が見えなくても起きるSQL注入と守り方 / 全86記事。全シリーズ記事はこちら

この記事の難易度

難易度:中級 / 読了目安:10分 / 学習順:#32

この記事で分かること
  • 結果が表示されなくても注入が危険な理由を理解する
  • Boolean-based と Time-based の観察点を知る
  • パラメータ化クエリの役割を説明できるようにする
この記事で出てくる言葉
  • SQLインジェクション:入力がSQL文の構造として解釈される脆弱性です。
  • Boolean-based:条件の真偽による画面や応答差を見る方法です。
  • Time-based:意図的な遅延の有無を手掛かりにする方法です。

🔍 観察フェーズ:まず何を見る?

最初から攻撃方法を探すのではなく、どの機能や設定が外から見えているかを整理するところから始めるよ。

  • 検索、ログイン、絞り込み、ID指定などDB問い合わせが発生する入力
  • 入力によって表示件数や応答時間に不自然な差が出ないか
  • クエリが文字列連結ではなくパラメータ化されているか

いきなり試すんじゃなくて、まず「どこが入口になり得るか」を整理するんだね。

💡 仮説フェーズ:なぜ危険になり得る?

観察した内容から、被害につながる条件を仮説として並べるよ。

仮説1

エラーメッセージを隠しても、SQLの構造へ入力を混ぜられる問題そのものは消えません。

仮説2

応答差が安定して観察できると、少しずつ条件を推測される可能性があります。

仮説3

アプリ用DBアカウントの権限が広すぎると、成立時の被害範囲も大きくなります。

🔬 検証フェーズ:安全に確かめる

検証の目的は、実在サービスを攻撃することではなく、自分のラボで仕組みと防御の効き方を理解することだよ。

学習用アプリで、パラメータ化された検索と文字列連結された検索のコード差を確認します。攻撃の再現は必ずCTF・ローカルラボに限定してください。

許可された環境で、結果だけじゃなく「なぜそうなったか」まで確認するんだね。

⚔️ 攻撃フェーズ:成立すると何が起きる?

ここでは実サービスへの手順ではなく、成立した場合の影響を押さえよう。

影響1

攻撃者にとって利用価値のある入口や情報が増え、次の侵害につながる可能性があります。

影響2

設定や権限の範囲によっては、情報漏えい・改ざん・業務停止などへ影響が広がります。

影響3

検知や記録が不足していると、侵害の発見や原因調査が遅れます。

🛡️ 防御フェーズ:守る側はどうするか

守りは「気をつける」では終わらせず、設定・実装・監視に落とし込もう。

対策1

SQL文と値を分離するパラメータ化クエリを使う

対策2

DBアカウントを必要最小限の権限にし、異常な問い合わせや遅延を監視する

対策3

入力検証やエラー抑制は補助対策として使い、根本対策の代わりにしない

🤝 大事なお約束

必ず守ってね

この記事で扱う確認・検証は、自分の環境、CTF、または明示的に許可された演習環境だけで行ってください。他人のサービスや端末に無断で試す行為は、不正アクセス等に該当するおそれがあります。学んだ知識は守る側で活用しましょう。

📝 まとめ

ブラインドSQLiの教訓は、「画面にデータが出なければ安全」ではないことです。SQLの構造と入力値を分離する設計が根本対策になります。

📖 参考資料

📖 次に読みたい

記事URLをコピーしました