はじめに

外部資産の調査（Reconnaissance）や脆弱性スキャンにおいて、最も無駄なコストの一つが「偽陽性（False Positive）」です。

特に近年のクラウド環境やSPA（Single Page Application）を採用したシステムでは、存在しないパスに対しても常に 200 OK を返す構成が珍しくありません。

例えば、以下のような典型的な探索対象パスにアクセスした場合を考えてみます。

/v2/api-docs
/v3/api-docs
/swagger-ui.html
/actuator
/actuator/env

本来であれば 404 Not Found や 403 Forbidden が返ることを期待しますが、一部の環境ではどのパスにアクセスしても同一のHTMLページが返されます。

このような資産に対してディレクトリ探索や脆弱性スキャンを実施すると、スキャナーは大量の「存在するように見えるエンドポイント」を検出してしまい、結果として調査効率が著しく低下します。

本記事では、この「万能200 OK」問題が発生する背景と、レッドチームがスキャン初期段階で高速に識別・除外するための実践的なアプローチを解説します。

Catch-All資産とは何か

正常なWebサーバーの挙動

一般的なWebサーバーでは、存在しないパスへアクセスすると以下のような応答が返されます。

GET /this-path-does-not-exist

HTTP/1.1 404 Not Found

この挙動によって、探索ツールは「存在するパス」と「存在しないパス」を区別できます。

Catch-All構成の挙動

一方、SPAやフロントエンドルーティングを採用している環境では、存在しないパスであっても同じページへフォールバックする設定がよく利用されます。

Nginxでは次のような設定が典型例です。

location / {
    try_files $uri $uri/ /index.html;
}

あるいは、

error_page 404 =200 /index.html;

のように404を200へ変換する構成も存在します。

結果として、

/
/api
/random-test-123456
/aaaaaaaaaaaaaaaaaaa

のすべてが同一レスポンスになります。

なぜスキャン結果が汚染されるのか

例えばDirsearchやFFUFが1000個のパスを検査した場合、

1000 Requests
↓
1000 Responses
↓
1000 × HTTP 200

という結果になります。

ステータスコードだけで判定している場合、

[200] /swagger-ui.html
[200] /actuator
[200] /admin
[200] /backup.zip

すべて有効なエンドポイントとして誤認識される可能性があります。

この状態では、

調査工数の増加
脆弱性スキャンの誤検知
レポート品質の低下

といった問題が発生します。

識別手法① ランダムパスによる事前判定

最も単純かつ効果的なのは、存在しないことが確実なランダムパスを送信する方法です。

例：

/recon_8f2c9a5d6b7147f0

もしこのパスに対しても 200 OK が返る場合、Catch-All構成である可能性が高くなります。

識別手法② レスポンス指紋の比較

単純なステータスコードだけでは誤判定が発生するため、以下の要素を比較します。

Body Hash

md5(response.text)

Title

<title>Unified Gateway</title>

Content Length

len(response.content)

これらがルートページと一致する場合、同一ページが返却されている可能性が高いと判断できます。

識別手法③ 自動化によるデノイズ

スキャンパイプラインへ事前判定を組み込むことで、大量のノイズを排除できます。

判定条件の例：

if (
    status_code == 200 and
    body_hash == base_hash and
    title == base_title
):
    mark_as_catch_all()

実運用では単一条件ではなく、

ステータスコード
Body Hash
タイトル
Content-Length

の複数条件を組み合わせる方が安定します。

実戦での運用ポイント

Catch-All資産と判定された場合でも、必ずしも価値がないわけではありません。

重要なのは、

「ディレクトリ探索対象から除外する」

ことであり、

「システム全体を調査対象外にする」

ことではありません。

探索戦略を切り替え、

DNS情報
サブドメイン構成
公開API
証明書情報
アプリケーション固有機能

など別の観点から調査を進める方が効率的です。

まとめ

レッドチームのReconにおいて重要なのは、

「見つけること」ではなく、「価値のある対象を素早く見極めること」

です。

万能200 OKを返すCatch-All資産は、一見すると大量の攻撃面が存在するように見えますが、その多くはスキャン結果を汚染するノイズです。

スキャン前にランダムパスによる事前判定を行い、レスポンスの指紋を比較することで、偽陽性を大幅に削減できます。

結果として、限られた時間とリソースを本当に分析すべき資産へ集中できるようになります。