BurpでのHTTP/2の操作

現在、多くのサーバがHTTP/2をサポートしています。そのせいで、HTTP/1しかサポートしていないツールでは見つけられない脆弱性が放置されている可能性があります。Burp Suiteは、HTTP/2ベースのテストに対して比類のないサポートを提供し、他のツールではできない方法でHTTP/2リクエストを操作できます。次のどちらでも可能です:

BurpのユニークなHTTP/2機能は、これまで適切なツールがまったくなかったためほとんど診断されていなかった、まったく新しい攻撃経路を探索する機会を与えてくれます。実際の例として、ある研究者がこれらの機能を利用して、リクエストスマグリングを行う新たな方法を発見し、悪用に成功した例を見てください。

PortSwigger Research

HTTP/2: The Sequel Is Always Worse

背景の概念

内部では、HTTP/2はHTTP/1と大きく異なります。これらの機能を最大限に活用するために、背景の関連する概念を簡単に説明しています。

デフォルトプロトコル

Burpはデフォルトで、TLSハンドシェイク時にALPNでHTTP/2のサポートを表明するサーバとの通信に、HTTP/2を使用します。これにより、プロトコルに特化したテストを行っていない場合でも、HTTP/2のおかげでパフォーマンスが向上します。

プロジェクトのデフォルトのプロトコルを変更すれば、現在のニーズに合わせてこの動作を調整できます。これは、常にHTTP/1を使用する必要があるテストを行っている場合に便利です。必要に応じて個別にHTTP/2リクエストを送信する場合は、Inspectorでプロトコルの切り替えができます。

どのプロトコルを使用しているかを把握

プロトコルレベルの脆弱性をテストする際には、各リクエストにどのプロトコルが使用されているかの認識が重要です。この情報が表示される場所はいくつかあります。

リクエストのプロトコル変更

デフォルトのプロトコル設定にかかわらず、各リクエストの送信に使用するプロトコルを手動で選択できます。これを行うには、Inspector > リクエスト属性のトグルスイッチを使います。

プロトコルを変更すると、Burpは必要な変換を行い、新しいプロトコルでの同等のリクエストを生成します。つまり、必要に応じて個々のリクエストを簡単にアップグレードやダウングレードできます。

デフォルトでは、サーバがTLSハンドシェイク中にALPNでHTTP/2のサポートを明示した場合にのみ、リクエストをアップグレードできます。こっそりHTTP/2をサポートしているかをテストするために、HTTP/2リクエストを送信してみたい場合は、まずRepeaterメニューからHTTP/2 ALPNを上書きするオプションを有効にする必要があります。

Inspectorで作業すると、HTTP/1の構文では正確に表現できないHTTP/2リクエストを、情報を失うことなく作成できます。Burpではこれを"ケトルな"リクエストと呼んでいます。このようなリクエストをダウングレードしようとすると、エディタで表示できるようにリクエストを正規化する必要があるとBurpが警告します。

ケトルなリクエスト

Inspectorを使えば、HTTP/1の構文では正確に表現できないようなHTTP/2リクエストを、情報を失うことなく作成できます。悪名高きDirector of ResearchのJames Kettleにちなんで、私たちはこのようなリクエストを"ケトルな"という言葉で表現しています。

たとえば、HTTP/2ではヘッダ値のに改行文字を入れることが技術的には可能です。HTTP/1では、改行がヘッダの終わりを示すため、それ以降は次のヘッダ名の始まりにしか見えず、これを表示する方法がありません。

一度リクエストがケトル化されると、メッセージエディタはもうそのリクエストに相当するHTTP/1を表示しようとはしません。メッセージの本文は見られます。そのリクエストがなぜケトルなリクエストだと判断されたのかを伝える通知が、ヘッダの代わりに表示されます。ケトルなリクエストのヘッダにさらに変更を加えたい場合は、Inspectorを使用する必要があります。

現在、Burp Proxy、Repeater、Logger、Scannerは、ケトルなリクエストをサポートしています。Intruderなどのケトルなリクエストをサポートしていないツールに送ると、エディタで表示できるように正規化されます。

リクエストがケトル化する原因は?

Inspectorを使って次のような変更を行うと、ケトルなリクエストになります:

リクエストの逆ケトル化

リクエストを誤ってケトル化してしまった場合、それを復元する方法がいくつか有ります。次のことが可能です:

ケトルなリクエストと拡張

拡張は、ケトルなリクエストを新たに生成し送信できるので、HTTP/2ベースのテストをする拡張を開発できます。ただし現在のところ、Burpが最初に発行したケトルなリクエストを、拡張で修正はできません。これは、Burpのリクエストに対して、正規化されたHTTP/1スタイルの表現でしかアクセスできないためです。

HTTP/2設定

Burpには、HTTP/2の動作を調整する設定がいくつかあります。

デフォルトプロトコルの変更

Burpはデフォルトで、TLSハンドシェイク時にALPNでHTTP/2のサポートを表明するサーバとの通信に、HTTP/2を使用します。しかしデフォルトのプロトコルを変更すれば、HTTP/2リクエストを送信するよう明示的に指示しない限り、HTTP/1を使用するようにできます。これを行うには、Projectオプション > HTTP > HTTP/2を開き、サーバがサポートしている場合、デフォルトでHTTP/2にするオプションの選択を解除します。

古典的なCL.TEやTE.CLのリクエストスマグリングのような、特にHTTP/1を必要とする脆弱性に焦点を当てている場合は、これが必要でしょう。

個々のリクエストでこのグローバル設定を上書きするには、Inspector > リクエスト属性で、プロトコルのトグルを使用してください。

RepeaterのHTTP/2オプション

画面上部のRepeaterメニューから、HTTP/2リクエストを処理する際のBurp Repeaterの動作を制御する次のオプションにアクセスできます。

クロスドメインのリダイレクトでプロトコル選択を強制する

Repeaterはデフォルトで、クロスドメインでリダイレクトされた場合、通常通りプロトコルをネゴシエートします。このオプションを有効にすると、Inspector > リクエスト属性で選択されているのと同じプロトコルを使用してクロスドメインのリダイレクトをたどります。これは、クロスドメインリクエストを引き起こすようなHTTP/2特有の脆弱性をテストしている場合に重要です。

HTTP/2接続を再利用する

Repeaterはデフォルトで、複数のHTTP/2リクエストに同じ接続を再利用します。サーバによっては、各接続の最初のリクエストとそれ以降のリクエストの扱いが異なるため、脆弱性が断続的に現れたり、完全に見逃すこともあります。あるいは、あるリクエストがサーバは落とさずに接続を破壊していて、その後のすべてのリクエストの処理が裏で影響を受けていることがあります。

これらの問題が発生した場合はこのオプションを無効にして、送信するリクエストが常に接続後の最初のリクエストになるようにすると、問題を軽減できるかもしれません。

HTTP/2接続でConnectionヘッダを削除

デフォルトで、HTTP/2リクエストにConnectionヘッダがある場合、Burpはリクエストをサーバに送信する前にこれを削除します。これは、多くのHTTP/2サーバがこのヘッダを含むリクエストを拒否するためです。

それでもConnectionヘッダを送信する実験をしたい場合は、このオプションを無効にしてください。

HTTP/2 ALPNを上書きする

このオプションを選択すると、サーバがHTTP/2をサポートしていることをALPNで広告していない場合でも、Burp RepeaterからHTTP/2リクエストを送信できます。これにより、Burp Scannerが報告する"隠れたHTTP/2"の攻撃経路の探索や、隠れたHTTP/2サポートを手動でテストできます。

ProxyリスナーでHTTP/2の無効化

まれに、クライアントのHTTP/2実装に問題がある場合など、クライアントとBurpのProxyリスナーとの接続でHTTP/2を無効にしたい場合があります。その場合は、ユーザオプション > その他に移動し、該当するリスナーを選択し、編集をクリックします。ダイアログで、HTTP/2タブに移動し、HTTP/2のサポートチェックボックスの選択を解除します。これによりBurpは、クライアントがHTTP/2を使用したい場合でも、HTTP/1しか受け付けません。

これはBurpとサーバ間の接続には影響しないことに注意してください。

今後のBurpのHTTP/2機能の強化について

BurpのHTTP/2サポートにはいくつかの制限があります。現在、以下のような機能拡張を行っています。

ケトルなのリクエストへの対応強化

現時点では、Burpのツールの中には、ケトルなリクエストを処理できないツールが、Burp Intruderなどいくつかあります。今後のリリースでは、Burpのすべてのツールで、ケトルなリクエストを扱えることを目指しています。