脆弱性診断の報告書に、こう書かれていることがあります。「SQLインジェクションの兆候が見られるが、エラー内容や検索結果が画面に出力されないため、情報窃取のリスクは限定的」。
この一文を根拠に、修正の優先度を下げた経験がある方は少なくないはずです。画面に出ないなら、攻撃者も中身を読めないだろうという理屈は、直感的には筋が通っています。
しかし、この前提が成り立たない攻撃の形があります。攻撃者はアプリの応答を読みません。代わりに、データベースサーバー自身に、攻撃者のサーバーへ通信させます。データはその通信に乗って出ていきます。画面には最後まで何も表示されません。
応答を読まずにデータを持ち出す
SQLインジェクションは、結果の受け取り方で3つに分かれます。
| 種類 | データの受け取り方 | 画面での見え方 |
|---|---|---|
| 通常型 | 検索結果やエラーに混ぜて表示させる | 出力に現れる |
| ブラインド型 | 条件の真偽や応答時間の差から1文字ずつ推測する | 出力には現れない |
| アウトオブバンド型 | DBサーバー自身に外部へ通信させ、その通信に乗せる | 出力には現れない |
診断で「限定的」と判断されがちなのは、2つめのブラインド型を想定しているからです。ブラインド型は1文字ずつ推測するため大量のリクエストが必要で、実際に遅く、検知もされやすい。「理屈上は可能だが現実的でない」という評価には根拠があります。
3つめが変えるのはそこです。DBサーバーがネットワークへ出られる場合、抽出した文字列を攻撃者が管理するドメイン名の一部に埋め込み、DBに名前解決をさせる。攻撃者は自分のDNSサーバーのログを見るだけで、埋め込まれた内容を読み取れます。1回の通信で、まとまった量が出ていきます。
DBMSごとに使われる機能は違いますが、外部と通信しうる仕組みは各製品に存在します。Oracle の UTL_HTTP のようなネットワーク用パッケージ、SQL Server でUNCパスを参照する系統のストアドプロシージャ、Windows上のMySQLでのファイル読み込み関数などが、この文脈でよく挙げられます。共通しているのは、どれも本来は正当な用途がある機能だという点です。
なぜ手前の対策をすり抜けるのか
この形が見落とされる理由は、監視している方向と、データが出ていく方向が違うことにあります。
多くの構成では、防御はリクエストの入口に寄っています。WAFで不審なパターンを弾き、アプリのログで異常なリクエストを追う。出ていく側については、Webサーバーの応答を見ています。
アウトオブバンド型では、データはWebサーバーの応答に乗りません。DBサーバーから直接、外へ出ます。Webの経路をどれだけ厳しく見ていても、そこには痕跡が残りません。WAFを通過するリクエスト自体は、パラメータに文字列が入っているだけの、見慣れた形をしていることもあります。
加えて、DNSは多くの環境で素通りします。HTTPの外向き通信は制限していても、名前解決まで止めている組織は多くありません。「DBサーバーからインターネットへは出られない」と思っていても、DNSだけは通るという構成は珍しくないということです。
確認する順番
対策は新しいものではありません。順番が重要です。
1. SQLの組み立てから値を追い出す
プレースホルダ（プリペアドステートメント）を使い、値をSQL文の組み立てに混ぜないこと。これが根本対策で、ここが済めば以降の層は保険になります。文字列連結でSQLを組んでいる箇所が残っていないかは、コード全体で確認する必要があります。基本的な考え方はWebセキュリティの基礎にまとめています。
2. DBの実行権限を絞る
アプリが使う接続ユーザーに、外部通信を伴う機能の実行権限が要るケースはまずありません。不要な権限を落としておけば、侵入されても手段が減ります。ここは設定変更だけで済むため、費用対効果が高い部分です。
3. DBサーバーの外向き通信を制限する
アプリケーションサーバーの外向きは意識されていても、DBサーバーは「内側だから」と素通しになっていることがあります。DBサーバーがインターネットへ出る必要が業務上あるかを確認し、無いなら塞ぐ。DNSについては、社内の権威サーバーやリゾルバ経由に限定し、外部への直接問い合わせを止めます。
4. 遮断された通信を記録する
塞いだうえで、遮断されたログを残します。ここに記録が出ること自体が、侵入の兆候になります。
診断そのものの読み方や、指摘をどう優先度付けするかは中小企業のための脆弱性診断ガイド、外部サービスを含めた評価軸はセキュリティ評価の進め方を参照してください。
検収・保守契約に書いておくこと
外部に開発を委託している場合、この層は「書いていなければやらない」領域になりがちです。アプリが仕様どおり動くことと、DBサーバーの外向き通信が塞がっていることは、担当範囲として別だと解釈されることがあるためです。
要件として明示しておくと後の揉め事が減ります。
- SQLの組み立てにプレースホルダを使用し、文字列連結で組む箇所を残さないこと
- アプリケーション用のDB接続ユーザーに、ネットワーク通信を伴う機能の実行権限を付与しないこと
- DBサーバーからインターネットへの外向き通信（DNSを含む）を既定で拒否し、必要な宛先のみ許可すること
- 拒否された外向き通信をログとして記録し、保守の監視対象に含めること
3つめの「DNSを含む」を明記するかどうかで、実際の設定が変わります。単に「外部通信を制限する」と書くと、HTTPだけ塞いで終わるのが一般的だからです。
なお、遅い・重いといった性能面の受け入れ条件も同じ構造で、書いていないと検収で見つかりません。あわせて一覧ページの遅さとN+1の受け入れ条件も確認しておくと、契約書に落とす項目がまとめて整理できます。
次にやること
自社のDBサーバーから、外部のドメイン名が解決できるかどうかを確認してください。そこが通るなら、画面に何も出力されない脆弱性であっても、データが出ていく経路は存在します。
そのうえで、過去の診断報告書を見返します。「出力されないため影響は限定的」という理由で保留にした指摘があれば、その前提はDBサーバーの外向き通信が塞がっていて初めて成り立つものです。塞がっていないなら、優先度を付け直す必要があります。
既存システムの通信経路の棚卸しや、委託先との要件定義に落とす形での整理については、グリームハブの開発・AI・自動化のご相談で承っています。構成や運用体制によって現実的な打ち手は変わるため、個別にご相談ください。お問い合わせからどうぞ。
