SSTエンジニアブログ

SSTのエンジニアによるWebセキュリティの技術を中心としたエンジニアブログです。

Burp 2020.6でHTTP/2対応したから試してみた

はじめに

リゼロ2期が7/13配信なので待ちわびて仕事のやる気が起きない岩間です。
(まぁ最近アニメ見れてないんですけどね。それよりもFactorioとかProject WinterとOvercookedとか協力プレイ系のゲームが楽しくてゲーム三昧で寝不足気味)
Burp 2020.6からHTTP/2の試験的なサポートが開始されました!
ということで、Burpでどのように実装されたのか気になったので簡単に調べてみました。

余談ですが、HTTP/2と言えば弊社CTO長谷川が監修している「詳解HTTP/2」という本が先月出版されましたね(露骨な宣伝)。

HTTP/2有効化設定

まだ正式なものではないため、デフォルトではHTTP/2対応が無効化されています。
[Project options] -> [HTTP] から Enable HTTP/2 (Experimental) をチェックしてください。

f:id:wild0ni0n:20200709143156p:plain

これでHTTP/2が有効化されました。

HTTP/2通信の確認

今回は、九州セキュリティカンファレンスで発表した際に使用した環境(http2-lab)を使用し、以下の方法でHTTP/2通信が行われているか確認しました。

  • Chromeのイベントログによる確認
  • curlコマンドによる確認

Chromeのイベントログによる確認

Chromeにはネットワーク関連のトラブルシューティング用ツールが提供されています。
参考: Chrome のネットワークの問題に関するトラブルシューティング

使用方法は割愛します。ログ記録を有効にし、Burp Proxyを通過するように設定した状態で、http2-labにアクセスしてみます。

f:id:wild0ni0n:20200709143610p:plain
http2-labの画面

アクセス後、ログの記録を停止し、イベントログからHTTP/2セッションが張れているか確認します。

f:id:wild0ni0n:20200709144052p:plain
HTTP/2セッション

ちゃんとHTTP/2通信が行われているようですね! もう少し通信の中身を確認するために、このセッションで送受信されているHEADERSフレームを確認します。

f:id:wild0ni0n:20200709145054p:plain
HEADERSフレームの内容

HTTP/2の形式でリクエストとレスポンスを送受信していることが分かります。

curlコマンドによる確認

curlはHTTPリクエストを送る定番ツールですが、--http2オプションを指定することで、HTTP/2通信が行えます。

Burp(http://localhost:8080)のプロキシ設定を行い、curlでhttp2-labにアクセスしてみます。

root@mypc:/mnt/c/Users/iwama# curl -vk -s --http2 https://http2-lab  -o /dev/null -x http://localhost:8080
* Rebuilt URL to: https://http2-lab/
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 8080 (#0)
* allocate connect buffer!
* Establish HTTP proxy tunnel to http2-lab:443     
> CONNECT http2-lab:443 HTTP/1.1
> Host: http2-lab:443
> User-Agent: curl/7.58.0
> Proxy-Connection: Keep-Alive
>
< HTTP/1.0 200 Connection established 
<
* Proxy replied 200 to CONNECT request
* CONNECT phase completed!
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt  
  CApath: /etc/ssl/certs
...(省略)...
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: C=PortSwigger; O=PortSwigger; OU=PortSwigger CA; CN=http2-lab
*  start date: Jun 23 03:19:22 2020 GMT
*  expire date: Jun 23 03:19:22 2021 GMT
*  issuer: C=PortSwigger; ST=PortSwigger; L=PortSwigger; O=PortSwigger; OU=PortSwigger CA; CN=PortSwigger CA
*  SSL certificate verify result: self signed certificate in certificate chain (19), continuing anyway.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
...(省略)...
> GET / HTTP/2
> Host: http2-lab
> User-Agent: curl/7.58.0
> Accept: */*
>
...(省略)...
< HTTP/2 200
< server: nginx/1.15.2
< date: Thu, 09 Jul 2020 06:05:24 GMT
< content-type: text/html; charset=UTF-8
< x-powered-by: PHP/7.2.8
<
...(省略)...

ALPN, offering h2 のメッセージから、curlがHTTP/2に対応していることが分かります。
(直後にALPN, offering http/1.1のメッセージが表示されていることから、curlはHTTP/2とHTTP/1.1に対応している)
server accepted to use h2 のメッセージから、サーバはALPNによるネゴシエーションでHTTP/2を選択していることが分かります。

簡易的な検証ですが、上記の結果からHTTP/2通信が出来ていることが確認できました。

BurpでHTTP/2通信の中身を改ざんできるか確認

BurpでHTTP/2通信の中身を改ざん出来るか調べてみました。
結論から言うと出来ないようです。

Interceptした結果では、HTTP/2ではなくHTTP/1.xの形式で表示されていました。 また、HTTP historyタブのリクエスト/レスポンスを確認してもHTTP/1.xの形式でした。

f:id:wild0ni0n:20200709153136p:plain
HTTPリクエスト/レスポンス

改ざんしてもHTTP/2通信は保ったままでしたが、HTTP/2の形式でリクエストやレスポンスを操作するといったことは出来ませんでした。

なので、例えばHTTP/2疑似ヘッダー(pseudo header)を改ざんして送ったり、HTTP/2のセマンティクスを無視したような構造のリクエストを作るといったことは出来ません。
(そもそもそのような検証が必要かどうかは、今回の趣旨とは異なるので述べません。)

その他にもサーバプッシュ通信には対応していないようです。(interceptもできず、historyにも表示されない。)

2020/7/27追記:

Burp 2020.7リリースで、初回の通信を除いてHTTP/2形式のリクエストとレスポンスに対応しました。初回の通信のみHTTP/1.Xで通信が行われます。
ただし、HTTP/2疑似ヘッダー(pseudo header)を改ざんして送ったり、HTTP/2のセマンティクスを無視したような構造のリクエストを作るといったことは出来ませんでした。

おわりに

forumやTwitterの情報などを見ているとHTTP/2通信対応の要望は、かなーり前からありました。
まだかまだかと待ちわびていましたが、ようやくリリースされましたね!(といってもまだExperimental!)

それではよいBurpライフを!