WCVS (Web Cache Vulnerability Scanner) の使い方ガイド 🔎

Webキャッシュの脆弱性を発見し、アプリケーションを保護する方法

目次

はじめに：WCVSとは何か？🤔

Web Cache Vulnerability Scanner（WCVS）は、Webキャッシュポイズニング (Web Cache Poisoning) や Webキャッシュデセプション (Web Cache Deception) といった、Webキャッシュに関連するセキュリティ脆弱性を検出するために設計されたオープンソースのコマンドラインツールです。Hackmanit GmbH と Maximilian Hildebrand によって開発されました。

現代のWebアプリケーションでは、パフォーマンス向上のためにキャッシュが広く利用されています。キャッシュは、ユーザーへのレスポンス時間を短縮し、サーバーの負荷を軽減する重要な役割を担っています。しかし、設定の誤りや不十分なカスタマイズは、深刻なセキュリティリスクを引き起こす可能性があります。WCVSは、これらのリスクを特定し、開発者やセキュリティ担当者が対策を講じる手助けをします。

Webキャッシュポイズニングとは？ ☠️

Webキャッシュポイズニングは、攻撃者が意図的に不正なデータをWebキャッシュに保存させる攻撃手法です。攻撃者は、脆弱なWebアプリケーションに対して悪意のあるHTTPレスポンスを生成させ、それをキャッシュさせます。一度キャッシュされると、そのキャッシュエントリが有効期限切れになるまで、正規のユーザーに対しても汚染されたコンテンツが提供され続けます。これにより、攻撃者はユーザーに悪意のあるスクリプトを実行させたり（XSS）、不正な情報を提供したりすることが可能になります。

キャッシュサーバーは通常、リクエストの特定の要素（キャッシュキー、通常はホストヘッダーとリクエストパス）を見て、以前のリクエストと同じかどうかを判断します。キーが一致すれば、バックエンドサーバーに問い合わせることなくキャッシュされたレスポンスを返します。攻撃者は、キャッシュキーに含まれないヘッダー（Unkeyed Header）やパラメータ（Unkeyed Parameter）を悪用して、異なるコンテンツを同じキャッシュキーでキャッシュさせようとします。

Webキャッシュデセプションとは？ 🎭

Webキャッシュデセプションは、攻撃者がキャッシュサーバーを騙して、本来キャッシュすべきでない機密情報を含む動的コンテンツを静的リソースとしてキャッシュさせてしまう攻撃です。多くの場合、攻撃者は動的なURLの末尾に偽の静的ファイル拡張子（例：/user/profile を /user/profile/dummy.css に変える）を追加したリンクをユーザーにクリックさせます。キャッシュサーバーがURLの拡張子だけを見て静的ファイルと誤認し、そのユーザー向けの個人情報が含まれたページをキャッシュしてしまうと、次に同じURLにアクセスした別のユーザーにその情報が漏洩する可能性があります。

WCVSは、これらの複雑な脆弱性を効率的に検出するための多様な機能を備えています。

WCVSの主な機能 ✨

  • 多様な攻撃テクニックのサポート: 9種類のWebキャッシュポイズニング技術と複数のWebキャッシュデセプション技術に対応しています。
    • ポイズニング: Unkeyed Header Poisoning, Unkeyed Parameter Poisoning, Parameter Cloaking, Fat GET, HTTP Response Splitting, HTTP Request Smuggling, HTTP Header Oversize (HHO), HTTP Meta Character (HMC), HTTP Method Override (HMO).
    • デセプション: Path Parameter, Path Traversal (異なるファイル拡張子やパス), 特殊文字の追加（エンコードあり/なし）。
  • 自動キャッシュ分析と適応: スキャン前にWebキャッシュの挙動を分析し、テストを最適化します。
  • クローラー機能: サイト内をクロールして、テスト対象となる追加のURLを発見します。
  • レポート生成: スキャン結果をJSON形式で出力し、CI/CDパイプラインへの統合を容易にします。
  • プロキシ経由のトラフィック: Burp Suiteなどのプロキシツールを通じてリクエストをルーティングできます。
  • リクエストレート制限: サーバーへの負荷軽減やレートリミット回避のため、秒間リクエスト数を制限できます。
  • カスタマイズ性: 多くのオプションフラグにより、スキャンを細かく制御できます。

インストール方法 💻

WCVSはいくつかの方法でインストールできます。

方法1: 事前ビルド済みバイナリ

開発者が提供するビルド済みのバイナリをGitHubのリリースページからダウンロードするのが最も簡単な方法です。これらのリリースには、デフォルトのワードリストも含まれています。ダウンロード後、実行権限を与えればすぐに使用できます。

方法2: Kali Linux / BlackArch リポジトリ

主要なペネトレーションテスト用OSの公式リポジトリからもインストールできます。

Kali Linux:

sudo apt update && sudo apt install web-cache-vulnerability-scanner

BlackArch:

sudo pacman -Syu wcvs

方法3: Go言語を使用してインストール

Go言語 (バージョン 1.21以上) がインストールされていれば、以下のコマンドでインストールできます。 

go install -v github.com/Hackmanit/Web-Cache-Vulnerability-Scanner@latest

インストール後、$GOPATH/bin に実行ファイルが配置されるので、パスが通っていることを確認してください。

方法4: Dockerを使用

Docker環境でWCVSを実行することも可能です。

  1. リポジトリをクローンするか、ソースコードをダウンロードします。 
    git clone https://github.com/Hackmanit/Web-Cache-Vulnerability-Scanner.git
cd Web-Cache-Vulnerability-Scanner
  2. Dockerイメージをビルドします。 
    docker build -t wcvs-image .
  3. ビルドしたイメージを使用してWCVSを実行します。 
    docker run -it wcvs-image --help
    docker run -it wcvs-image -u https://example.com

基本的な使い方 🚀

WCVSの基本的な実行には、テスト対象のURLを指定する -u または --url フラグが必須です。

多くのキャッシュポイズニング技術（特にヘッダーやパラメータベースのもの）をテストするために、WCVSはヘッダー名とパラメータ名のワードリストを必要とします。デフォルトでは、WCVSを実行するディレクトリにある headers.txt と parameters.txt という名前のファイルを探します。これらのファイルがない場合や、別のワードリストを使用したい場合は、--headerwordlist/-hw および --parameterwordlist/-pw フラグでパスを指定します。

シンプルなスキャン例:

wcvs -u https://example.com

もしカレントディレクトリにワードリストファイルが存在しない場合は、以下のように指定します。 

wcvs -u https://example.com -hw /path/to/your/headers.txt -pw /path/to/your/parameters.txt

複数のURLをスキャン:

複数のURLをスキャンする場合は、カンマ区切りで指定するか、URLリストが含まれるファイルを使用します。 

# カンマ区切り
wcvs -u https://example.com,https://test.com

# ファイルから読み込み
wcvs -uf /path/to/urls.txt

出力の詳細度を変更:

-v または --verbosity フラグで出力の詳細度を調整できます。

  • 0: Quiet (静か、エラーのみ表示)
  • 1: Normal (通常、デフォルト)
  • 2: Verbose (詳細、デバッグに有用)
wcvs -u https://example.com -v 2

高度なオプションとカスタマイズ 🛠️

クローラー機能の利用

WCVSは内蔵のクローラーを使って、指定されたURLからリンクをたどり、新たなスキャン対象URLを発見できます。デフォルトでは無効になっていますが、--recursive/-r フラグで有効にし、探索の深さを指定できます。 

# 深さ2までクロール
wcvs -u https://example.com -r 2

他にもクロール動作を制御するフラグがあります。

  • --recdomains/-red: 他のドメインもクロール対象に含めます。
  • --recinclude/-rin: 特定の文字列を含むURLのみクロールします。
  • --reclimit/-rl: 各深さでクロールするURL数を制限します。
  • --recexclude/-rex: クロール対象から除外するURLのリスト（ファイルパス）を指定します。
  • --generatecompleted/-gc: スキャンが完了したURLのリストを生成します。これを次回のスキャンで -rex に指定することで、重複スキャンを防げます。
# 他ドメインも含め、'/admin' を含むURLを除外し、深さ3までクロール
wcvs -u https://example.com -r 3 -red -rex /path/to/exclude_list.txt

リクエストレートの調整

サーバーへの負荷を考慮したり、WAF（Web Application Firewall）によるブロックを回避したりするために、秒間リクエスト数を制限できます。--reqrate/-rr フラグを使用します。 

# 1秒あたり10リクエストに制限
wcvs -u https://example.com -rr 10

スレッド数を調整することでも間接的にレートを制御できますが、-rr の方がより直接的です。スレッド数は --threads/-t で指定します（デフォルトは20）。 

# スレッド数を5に制限
wcvs -u https://example.com -t 5

プロキシの設定

HTTPリクエストをBurp Suiteなどのプロキシ経由で送信したい場合、以下のフラグを使用します。

  • --proxyurl/-purl: プロキシサーバーのURL（デフォルト: http://127.0.0.1:8080）。
  • --proxycertpath/-ppath: プロキシのCA証明書（PEM形式）へのパス。HTTPSサイトをスキャンする場合に必要です。Burp Suiteの証明書はDER形式なので、OpenSSLなどで変換が必要です。
# Burp Suiteの証明書をPEMに変換 (例)
openssl x509 -inform DER -in cacert.der -out cacert.pem

# プロキシ経由でスキャン
wcvs -u https://example.com -purl http://127.0.0.1:8080 -ppath /path/to/cacert.pem

カスタムヘッダー、パラメータ、Cookieの指定

特定のリクエストヘッダー、URLパラメータ、Cookieをスキャンに追加したり、既存の値を上書きしたりできます。これらのフラグには直接値を指定するか、ファイルパスを指定できます。

  • --header/-hdr: カスタムヘッダー (例: "Authorization: Bearer token123")。
  • --parameter/-par: カスタムURLパラメータ (例: "debug=true")。
  • --cookie/-c: カスタムCookie (例: "sessionid=abcde12345")。
  • --useragent/-ua: User-Agentヘッダーを指定します。
  • --method/-m: HTTPメソッドを指定します（デフォルトはGET）。
# カスタムヘッダーとCookieを指定
wcvs -u https://example.com -hdr "X-Custom-ID: user-123" -c "lang=ja"

レポート生成

スキャン結果をJSON形式でファイルに出力するには、--generatereport/-gr フラグを使用します。出力先ディレクトリは --generatepath/-gp で指定できます（デフォルトはカレントディレクトリ）。 

# レポートを /tmp/wcvs_reports/ ディレクトリに生成
wcvs -u https://example.com -gr -gp /tmp/wcvs_reports/

--escapejson/-ej フラグを使うと、レポート内のHTML特殊文字をエスケープできます。CI/CDパイプラインなどでJSONを処理する場合に役立つことがあります。

生成されるJSONレポートの例（抜粋）:

{
  "name": "Web_Cache_Vulnerability_Scanner",
  "version": "1.3.3", // バージョンは実行時によって異なります
  "foundVulnerabilities": true,
  "hasError": false,
  "errorMessages": null,
  "date": "2025-03-31_14:50:00", // 実行日時
  "duration": "30.387642061s", // 実行時間
  "command": "wcvs -u https://example.com/ -gr", // 実行コマンド
  "config": { ... }, // 使用した設定
  "websites": [
    {
      "url": "https://example.com/",
      "isVulnerable": true,
      "hasError": false,
      "errorMessages": null,
      "results": [
        {
          "technique": "Forward/Host Headers", // 検出された手法
          "hasError": false,
          "errorMessages": null,
          "isVulnerable": true, // 脆弱性あり
          "requests": [
            {
              "reason": "Location header contains poison value 727356299485", // 脆弱性と判断された理由
              "request": "GET /?cb=595559747024 HTTP/1.1\\r\\nHost: example.com\\r\\n...", // 送信したリクエスト
              "response": "HTTP/2.0 302 Found\\r\\nLocation: https://727356299485/?cb=595559747024\\r\\n..." // 受信したレスポンス
            }
          ]
        },
        ... // 他のテスト結果
      ]
    }
  ]
}

特定のテストのみ実行 / スキップ

--onlytest/-ot フラグで実行したいテストの種類を指定したり、--skiptest/-st フラグで実行したくないテストを指定できます。テスト名はカンマ区切りで指定します。

利用可能なテスト名 (例): `deception`, `cookies`, `css`, `forwarding`, `smuggling`, `dos`, `headers`, `parameters`, `fatget`, `cloaking`, `splitting` など（バージョンによって異なる可能性があります。-hで確認してください）

# ヘッダーとパラメータ関連のポイズニングテストのみ実行
wcvs -u https://example.com -ot 'headers,parameters'

# リクエストスマグリングテストをスキップ
wcvs -u https://example.com -st 'smuggling'

その他の便利なフラグ

  • --force/-f: キャッシュが検出されなかった場合でも、強制的にテストを実行します。
  • --timeout/-to: リクエストのタイムアウト秒数を設定します（デフォルトは15秒）。
  • --stime/--skiptimebased: キャッシュヒット/ミスを判断する最後の手段として時間測定を使用しないようにします。時間測定は誤検知を引き起こす可能性があります。

結果の解釈 📊

WCVSはスキャンが完了すると、コンソールにサマリーを表示します。-gr フラグを使用した場合、詳細なJSONレポートが生成されます。

コンソール出力やJSONレポートの results 配列には、試行された各テクニックとその結果が含まれます。"isVulnerable": true となっている項目が、脆弱性が検出された箇所です。

脆弱性が検出された場合、requests 配列にその根拠となるリクエストとレスポンスのペアが記録されます。reason フィールドには、なぜそれが脆弱性と判断されたかの簡単な説明（例: “Location header contains poison value …”, “Response body differs” など）が記載されます。

例えば、Unkeyed Header Poisoning が検出された場合、レポートには以下のような情報が含まれる可能性があります。

  • 攻撃に使用されたキーに含まれないヘッダー（例: X-Forwarded-Host）。
  • 最初の（汚染用）リクエストと、そのレスポンス。
  • 二番目の（確認用、汚染用ヘッダーを含まない）リクエストと、そのレスポンス。
  • 二番目のレスポンスが、最初の（汚染された）レスポンスの内容を含んでいる（例：Locationヘッダーの値が汚染されている、レスポンスボディが書き換えられている）という証拠。

Web Cache Deception が検出された場合は、特定のパス（例: /profile/user.css）へのリクエストで、本来動的な内容（例: ユーザー固有の情報）がキャッシュされ、後続のリクエストでそのキャッシュされた内容が返されたことが示されます。

"hasError": true となっている場合は、そのテスト中に何らかのエラー（ネットワークエラー、タイムアウトなど）が発生したことを示します。エラーメッセージは errorMessages で確認できます。

脆弱性の緩和策・予防策 🛡️

WCVSによって脆弱性が検出された場合、以下のような対策を検討する必要があります。

Webキャッシュポイズニング対策

  • キャッシュキーの厳格化: キャッシュサーバーの設定を見直し、ユーザーごとに異なるべきコンテンツ（例：Authorizationヘッダーや特定のCookieに依存するコンテンツ）がキャッシュされないように、キャッシュキーに影響を与える要素を適切に定義します。可能であれば、レスポンスを変化させる可能性のある全ての入力（ヘッダー、パラメータ、Cookie）をキャッシュキーに含めることを検討します。
  • 未知のヘッダーの拒否/正規化: アプリケーションやキャッシュサーバーが、予期しないHTTPヘッダー（特にX-Forwarded-Hostのような上書き可能なヘッダー）を無視するか、適切に正規化するようにします。
  • Varyヘッダーの利用: HTTPレスポンスヘッダーの Vary を使用して、どのリクエストヘッダーに基づいてレスポンスが変化するかをキャッシュサーバーに伝えます。例えば、Vary: User-Agent, Accept-Language と指定すると、これらのヘッダーが異なるリクエストは別のキャッシュエントリとして扱われます。ただし、Vary を過度に使用するとキャッシュヒット率が低下する可能性があるので注意が必要です。
  • キャッシュ無効化: 動的なコンテンツや機密情報を含むレスポンスには、Cache-Control: no-store, private ヘッダーを付与して、キャッシュサーバーやブラウザキャッシュに保存されないようにします。
  • WAFの活用: Web Application Firewall を利用して、異常なヘッダーやリクエストパターンを検出し、ブロックします。

Webキャッシュデセプション対策

  • キャッシュ設定の見直し: CDNやキャッシュサーバーの設定で、URLの拡張子だけで静的/動的コンテンツを判断しないようにします。パス全体や明確なルールに基づいてキャッシュ対象を決定するように構成します。
  • 動的コンテンツの明示的なキャッシュ無効化: ユーザー固有の情報を含む可能性のある全ての動的ページには、必ず Cache-Control: no-store, private ヘッダーを付与します。
  • URL正規化の統一: バックエンドサーバーとキャッシュサーバーでURLの解釈や正規化の方法が異なる場合に問題が発生しやすいため、可能な限り挙動を統一します。
  • 厳格なルーティング: 未知のパスや予期しないパス構造を持つリクエストに対しては、デフォルトで安全なレスポンス（例: 404 Not Found）を返すようにアプリケーションを設定します。

これらの対策は、アプリケーションやインフラストラクチャの特性に応じて適切に組み合わせる必要があります。定期的なWCVSによるスキャンは、設定変更やコード改修によって新たな脆弱性が混入しないかを確認するために重要です。

まとめ 🎉

WCVS (Web Cache Vulnerability Scanner) は、Webキャッシュポイズニングやデセプションといった見過ごされがちな、しかし影響の大きな脆弱性を発見するための強力なツールです。多様なテスト手法、カスタマイズ可能なオプション、そしてCI/CDパイプラインへの統合可能性を備えています。

このガイドを参考にWCVSを活用し、Webアプリケーションのキャッシュ機構に潜むリスクを特定・修正することで、より安全なサービスを提供するための一助となれば幸いです。定期的なスキャンと適切な設定により、キャッシュの恩恵を受けつつ、セキュリティリスクを最小限に抑えましょう。🛡️✨

ツールの詳細や最新情報については、公式GitHubリポジトリを参照してください。

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

前の記事

[Goのはじめ方] Part13: 構造体（struct）の定…

次の記事

[Goのはじめ方] Part14: 構造体へのメソッド定義