本記事は、Webをよくわからない状態で脆弱性診断をしている方向けの内容になります。
自信のない方は、本記事の内容を参考に診断ツールの設定を見直してみてください。
目次
30秒でわかる要点
・結論：診断はFQDN/URLをスコープにするのが大原則です。
IP直打ちは誤判定・未到達・他社誤爆が起こり得ます。
・根拠：HTTP/1.1ではHostヘッダが必須です(同一IPで複数ドメインを区別できる)。
TLSではSNIで証明書を選びます。両者が噛み合って“正しいサイト”に届きます。
※本記事の想定は、Webサーバ(ミドルウェア)中心の簡易診断です。
Webアプリ診断ではURL・認証状態・キャッシュ等も含めた詳細な設計が必要になります。
技術的に“ホスト名指定”するべき理由
HTTP/1.1：Hostヘッダは必須
HTTP/1.1 では、すべてのリクエストで Host を送ることが必須です。
これにより、1つのIP上に同居する複数ドメイン（バーチャルホスト）をサーバ側で正しく選別できます。
Hostが無ければリクエストは正しく処理されず、多くの場合400エラーが応答されます。
TLS：SNIで正しい証明書を選ぶ
TLS標準は当初、接続先の「ホスト名(FQDN)」をサーバへ伝える仕組みが無く、1IP＝1証明書が前提でし
た。これを解消するのがSNI(Server Name Indication)で、クライアントはTLSハンドシェイクの冒頭に
目的ホスト名を送り、サーバは一致する証明書を提示できるようになりました。
HTTP/2 , 3： :authority と Host の継続性
HTTP/2 以降は、Hostの役割を擬似ヘッダ :authorityが担い、
HTTP2→HTTP1を跨ぐ中継ではHostに正しく変換される設計です。
IP直打ちで起こる“典型的な失敗”3パターン
別サイトに当たる／デフォルトサイトが出る
SNIとHostが一致しないため、多くの実装では証明書名不一致で警告になるほか、
サーバのデフォルト証明書・デフォルトバーチャルホストにフォールバックする可能性が高いです。
ブラウザが続行しても、それは対象サイトではない可能性が高いです。
CDN/共有IPで“誰かのIP”に当たる
多くのCDNはAnycastで同一IPを多数の顧客で共有します。SNIとHost(:authority)で顧客を識別します。
IP直打ちはCDNの共通エラーページや別顧客のドメインに当たり、誤検出／未検出を招きます。
可変IPのLBで“再現性が崩壊”
よく利用されるクラウドLBのAWS ALBは固定IPを前提とせずDNS名での利用が想定されています。
運用中に返されるIPが入れ替わるため、IPをスコープにすると、途中で他の企業を診断してしまい、
異常な診断結果になってしまったりする恐れがあります。
まとめ
IP直打ちの診断によってわかることもありますが、診断の優先度としては高くありません。
まずはホスト名指定での診断が基本であり、精度を高める目的で、IP直打ち時の診断をすることになります。
IP直打ち診断をすると、意図しないコンテンツが表示されないか、証明書の異常がないかのチェックなど、
確認できることはありますが、診断によって判明する事は限定的です。
とりあえず、ホスト名指定で診断できているのかを確認するようにしましょう。
補足
脆弱性診断時に、ホスト名の指定と併せて、どのIPアドレスに接続しに行くのかを指定することができる
ツールがあります。例えば、ホスト名をwww.secuavail.comにして、接続先を全く関係のないIPアドレスに
するといったイメージです。
これは、CDNやクラウドWAFがオリジンの前段にある構成で、オリジンの通信の受け口がインターネット
向けに空いているような場合に、ホスト名は環境に合わせて設定し、接続先をオリジン側の受け口に向ける
ことで、CDNやクラウドWAFを迂回して、脆弱性診断をすることができます。
迂回を阻止するには、CDN側でカスタムHTTPヘッダを挿入し、オリジン側でヘッダのチェックを行ったり、
オリジン側で送信元IPアドレスをWAFだけに制限したりする対策が必要になります。
ただ、診断ツールを使わなくとも、Hostsファイルの編集やLinuxのコマンドなどで接続可否のチェックは
できるので、迂回されないか不安な方は試してみるとよいかと思います。
記載されている会社名、システム名、製品名は一般に各社の登録商標または商標です。
当社製品以外のサードパーティ製品の設定内容につきましては、弊社サポート対象外となります。
