1. サポートセンター
  2. ドキュメント
  3. デスクトップ版
  4. ツール
  5. Proxy
  6. オプション
  7. 透過プロキシ

Burp Proxy: 透過プロキシ

Burpの透過プロキシサポートにより、プロキシ非対応クライアントが直接Proxyリスナーに接続できるようになります。対象アプリケーションがブラウザ外で動作するシッククライアントコンポーネントを採用している場合や、ブラウザのフレームワーク外で独自のHTTPリクエストを行うブラウザプラグインの場合に、このオプションが便利な場合があります。多くの場合これらのクライアントは、HTTPプロキシをサポートしていない、または使用するための簡単な設定方法を提供していません。

受信リクエストのリダイレクト

プロキシ非対応のクライアントを効果的にBurpに接続させるには、関連するホスト名のDNS名前解決を変更し、アプリケーションが使用するポートで透過プロキシを設定しておきます。

例えば、アプリケーションがexample.orgドメインを使い、HTTPとHTTPSを標準ポートで使っている場合、ローカルマシンにリダイレクトするようhostsファイルにエントリを追加する必要があります:

        127.0.0.1        example.org 

リダイレクトされたリクエストを受信するには、透過Burp Proxyリスナーを127.0.0.1:80127.0.0.1:443に作成する必要もあります。プロキシ非対応クライアントは、ドメイン名をローカルIPアドレスに名前解決し、そのインタフェースに直接リクエストを送信します。

透過プロキシモード

DNSを使ってクライアントリクエストをローカルリスナーにリダイレクトするのは簡単ですが、そのリクエストはHTTPプロキシが期待する通常形式のリクエストではないため、特別な透過プロキシモードが必要になります。

普通のHTTPを使っていた場合、プロキシスタイルのリクエストはこのようになります:

GET http://example.org/foo.php HTTP/1.1
Host: example.org

一方、非プロキシスタイルのリクエストはこのようになります:

GET /foo.php HTTP/1.1
Host: example.org

通常Webプロキシは、どの宛先ホストへリクエストを転送するか判断するために、リクエストの先頭行で完全なURLを受信する必要があります(Hostヘッダは宛先の決定に使われません)。透過プロキシが有効な場合、Burpは非プロキシスタイルのリクエストを受信すると、Hostヘッダの内容を解析して、そのリクエストの送信先として使います。

プロキシでHTTPSを使用するとき、クライアントは接続したい宛先ホストを特定するCONNECTリクエストを送信し、SSLネゴシエーションを実行します。しかしプロキシ非対応クライアントは、直接SSLネゴシエーションを実行し、宛先ホストと直接通信していると信じています。透過プロキシが有効な場合、Burpはクライアントと直接SSLネゴシエーションを行い、復号したリクエストからHostヘッダを解析します。

送信リクエストのリダイレクト

透過モードで実行している場合、Burpはデフォルトでそれぞれのリクエストから解析されたHostヘッダの宛先ホストにリクエストを転送します。しかし、関連するドメインのエントリをhostsファイルで変更していると、Burp自身もそのホスト名をローカルリスナーに名前解決してしまい、別の方法で設定しない限りリクエストが自分自身に転送され、無限ループが発生してしまいます。

この問題を解決するためには 2 つの方法があります:

関連して、プロキシ非対応クライアントのリクエストにHostヘッダが含まれていない場合に問題が発生します。このヘッダがなく、非プロキシスタイルのリクエストを処理すると、どの宛先ホストにリクエストを転送すべきかBurpが判断できません。

ここでも、この問題を解決するための 2 つの方法があります。全てのリクエストを同じ宛先ホストに転送する場合は、Proxyリスナーのリダイレクトオプションを使って、正しいIPアドレスにトラフィックが行くよう強制させられます。

異なるリクエストを異なるホストに転送する場合は、複数のProxyリスナーを使う必要があります:

SSL 証明書の処理

Burp Proxyリスナーで使用されるサーバSSL証明書を設定する様々なオプションがあります。デフォルトオプションの宛先ホストごとに証明書を自動生成する設定は、透過プロキシでは動かない場合があります。プロキシ非対応クライアントはリスナーと直接SSLネゴシエーションをし、CONNECTリクエストヘッダを送信しないため、クライアントが接続しようとしている宛先ホストを特定できません。ブラウザを含む多くのクライアントはClient Helloメッセージの"server_name"拡張をサポートし、クライアントがネゴシエートしようとしている宛先ホストが識別できます。この拡張が存在している場合、Burpは通常通りそのホスト名を証明書の生成に使用します。しかし、Client Helloメッセージにその拡張がない場合は、Burpはフェイルオーバーとして静的な自己署名証明書を使用します。

送信リクエストのリダイレクトを使って、この問題を解決する2つの方法があります: